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.

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.

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.

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.

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.

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.

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.

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.

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;
  }
}

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.