View mode: basic / threaded / horizontal-split · Log in · Help
May 07, 2012
Re: run-time stack-based allocation
That won't do. This is way too ugly, considering, that it needs to be
heavily used in user code. I'm thinking an inline ASM solution, but
can't figure out when to deallocate.

On Mon, May 7, 2012 at 8:52 PM, Arne <arne@linux.nu> wrote:
> On Monday, 7 May 2012 at 16:03:15 UTC, Mehrdad wrote:
>>
>> On Monday, 7 May 2012 at 13:36:02 UTC, Gor Gyolchanyan wrote:
>>>
>>> Basically I want what alloca does, but instead of considering the
>>> constructor's scope, I want it to hand to the constructor call's enclosing
>>> scope.
>>
>>
>> I think you'd need to modify the compiler for this, since alloca is
>> 'magical'.
>
>
> wouldn't mixin's be a solution, one can inject an alloca to the current
> scope, and then call the constructor...
>
> import std.stdio;
> import std.c.stdlib;
> import std.random;
>
> mixin template Init(alias var, alias size)
> {
>  void* buf = alloca(size);
>
>  bool foo_init()
>  {
>    var = (cast(typeof(var))buf);
>
>    var[0]=0;
>    var[1]=1;
>    var[2]=2;
>
>    return true;
>  }
>
>  auto foo_dummy_statement = foo_init();
> }
>
> void main()
> {
>  int my_size = uniform(12, 24);
>  int* my_var = void; mixin Init!(my_var, my_size);
>
>  writeln(my_var[0..3]);
> }



-- 
Bye,
Gor Gyolchanyan.
May 07, 2012
Re: run-time stack-based allocation
On Monday, 7 May 2012 at 16:52:18 UTC, Arne wrote:
>> I think you'd need to modify the compiler for this, since 
>> alloca is 'magical'.
>
> wouldn't mixin's be a solution, one can inject an alloca to the 
> current scope, and then call the constructor...

Yeah, but mixins are so hacky.
They're like C macros, basically.
May 07, 2012
Re: run-time stack-based allocation
On Monday, 7 May 2012 at 20:20:34 UTC, Mehrdad wrote:
> On Monday, 7 May 2012 at 16:52:18 UTC, Arne wrote:
>>> I think you'd need to modify the compiler for this, since 
>>> alloca is 'magical'.
>>
>> wouldn't mixin's be a solution, one can inject an alloca to 
>> the current scope, and then call the constructor...
>
> Yeah, but mixins are so hacky.
> They're like C macros, basically.

/rant

Well, I think if the world had never seen all the bad
side-effects from 'C macros', most people would wholeheartedly
embrace mixin's today... since it cleanly avoids 'x' number of
design pitfalls from #define.

For maintenance, performance, portability considerations I
definitely prefer mixin's over reimplementing alloca for every
current and future targets/calling conventions.
May 07, 2012
Re: run-time stack-based allocation
On Monday, 7 May 2012 at 20:20:34 UTC, Mehrdad wrote:
> Yeah, but mixins are so hacky.
> They're like C macros, basically.

I'd have to say that C macros have many, _many_ more pitfalls 
than mixins.
May 07, 2012
Re: run-time stack-based allocation
Le 07/05/2012 13:58, Gor Gyolchanyan a écrit :
> I'm working on dynamic memory layout manager. Simply put, it will
> allow one to create and use struct types at run-time.
> Normally, you create a struct at compile-time type by specifying an
> ordered list of fields, each with its own type (basically a size) and
> name.
> You then access those fields by calling a compile-time evaluated dot
> operator, which computes the address of the specified field given the
> address of the struct.
> What I'm trying to make is precisely that, except at run-time.
>
> My question is: what is the best way of allocating such a structure on
> the stack? It will, of course, have a dynamically known size.
>

About that, I already had the need to return a variable that will be 
qualified as scope after the return.

It would also be usefull to safely implement stack allocator.
May 07, 2012
Re: run-time stack-based allocation
Yes! I really want it! There are tons of instances when a heap
allocation is done instead of stack allocation because of dynamic size
alone. If its lifetime is limited by a scope (any scope) - it doesn't
belong on the heap!

On Tue, May 8, 2012 at 2:07 AM, deadalnix <deadalnix@gmail.com> wrote:
> Le 07/05/2012 13:58, Gor Gyolchanyan a écrit :
>
>> I'm working on dynamic memory layout manager. Simply put, it will
>> allow one to create and use struct types at run-time.
>> Normally, you create a struct at compile-time type by specifying an
>> ordered list of fields, each with its own type (basically a size) and
>> name.
>> You then access those fields by calling a compile-time evaluated dot
>> operator, which computes the address of the specified field given the
>> address of the struct.
>> What I'm trying to make is precisely that, except at run-time.
>>
>> My question is: what is the best way of allocating such a structure on
>> the stack? It will, of course, have a dynamically known size.
>>
>
> About that, I already had the need to return a variable that will be
> qualified as scope after the return.
>
> It would also be usefull to safely implement stack allocator.



-- 
Bye,
Gor Gyolchanyan.
May 08, 2012
Re: run-time stack-based allocation
On 5/7/2012 12:08 PM, Gor Gyolchanyan wrote:
> Wasn't there an allocator mechanism under development for phobos? I
> remember there was a StackAllocator, that can span for arbitrary
> scopes. What's up with that?

I wrote one.  It's at https://github.com/dsimcha/TempAlloc .  It hasn't 
been accepted to Phobos, though, because of issues w.r.t. figuring out 
what a more general allocator interface should look like.
May 08, 2012
Re: run-time stack-based allocation
Cool! Thanks! I'l definitely check it out! I hope it's DDOCed :-D

On Tue, May 8, 2012 at 5:29 AM, dsimcha <dsimcha@yahoo.com> wrote:
> On 5/7/2012 12:08 PM, Gor Gyolchanyan wrote:
>>
>> Wasn't there an allocator mechanism under development for phobos? I
>> remember there was a StackAllocator, that can span for arbitrary
>> scopes. What's up with that?
>
>
> I wrote one.  It's at https://github.com/dsimcha/TempAlloc .  It hasn't been
> accepted to Phobos, though, because of issues w.r.t. figuring out what a
> more general allocator interface should look like.



-- 
Bye,
Gor Gyolchanyan.
May 09, 2012
Re: run-time stack-based allocation
On Tuesday, 8 May 2012 at 07:03:35 UTC, Gor Gyolchanyan wrote:
> Cool! Thanks! I'l definitely check it out! I hope it's DDOCed 
> :-D
>

I just invented an absolutely wicked way of using alloca() in the 
parent context... unfortunately frame_size is static but with 
some work, it's still an usable method since it's mutable!

struct Wicked
{
  static int frame_size = 0;

  auto Create(void* buf=alloca(frame_size))
  {
    for(byte i=0;i<frame_size;++i)
      (cast(byte*)buf)[i]=i;

    struct Frame
    {
      size_t size;
    }

    Frame* xxx = cast(Frame*)buf;
    xxx.size=frame_size;

    return xxx;
  }

  @disable this();

  this(size_t size)
  {
    frame_size = size;
  }
}
May 09, 2012
Re: run-time stack-based allocation
I thought function default parameters need to be statically known...
isn't it the case?

On Thu, May 10, 2012 at 12:17 AM, Tove <tove@fransson.se> wrote:
> On Tuesday, 8 May 2012 at 07:03:35 UTC, Gor Gyolchanyan wrote:
>>
>> Cool! Thanks! I'l definitely check it out! I hope it's DDOCed :-D
>>
>
> I just invented an absolutely wicked way of using alloca() in the parent
> context... unfortunately frame_size is static but with some work, it's still
> an usable method since it's mutable!
>
> struct Wicked
> {
>  static int frame_size = 0;
>
>  auto Create(void* buf=alloca(frame_size))
>  {
>    for(byte i=0;i<frame_size;++i)
>      (cast(byte*)buf)[i]=i;
>
>    struct Frame
>    {
>      size_t size;
>    }
>
>    Frame* xxx = cast(Frame*)buf;
>    xxx.size=frame_size;
>
>    return xxx;
>  }
>
>  @disable this();
>
>  this(size_t size)
>  {
>    frame_size = size;
>  }
> }



-- 
Bye,
Gor Gyolchanyan.
1 2 3
Top | Discussion index | About this forum | D home