www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - alloca() in D

reply Mehrdad <wfunction hotmail.com> writes:
I think D should really have a friendlier interface to stack-based data 
structures than just alloca() (unless it already does and I don't know 
about it).

Some features which I think would be helpful:
- An "automatic" array-like structure entirely on the stack that starts 
out with a capacity given by the user), and which switches to the heap 
if it gets too big.
- A function that can just allocate a structure easily on the stack, 
taking care of constructors and whatnot... something like alloca!Foo() 
to allocate Foo on the stack, and alloca!Foo(5) to allocate Foo[] with a 
length of 5 on the stack (NOT Foo[5], obviously...), etc.

How does this sound?
Aug 05 2011
next sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
--0016e6d27cc9d51ecf04a9d0b81a
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Aug 5, 2011 at 11:35 PM, Mehrdad <wfunction hotmail.com> wrote:

 I think D should really have a friendlier interface to stack-based data
 structures than just alloca() (unless it already does and I don't know about
 it).

 Some features which I think would be helpful:
 - An "automatic" array-like structure entirely on the stack that starts out
 with a capacity given by the user), and which switches to the heap if it
 gets too big.
 - A function that can just allocate a structure easily on the stack, taking
 care of constructors and whatnot... something like alloca!Foo() to allocate
 Foo on the stack, and alloca!Foo(5) to allocate Foo[] with a length of 5 on
 the stack (NOT Foo[5], obviously...), etc.

 How does this sound?

http://d-programming-language.org/phobos/std_typecons.html#scoped --0016e6d27cc9d51ecf04a9d0b81a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Fri, Aug 5, 2011 at 11:35 PM, Mehrdad <span d= ir=3D"ltr">&lt;<a href=3D"mailto:wfunction hotmail.com">wfunction hotmail.c= om</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg= in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> I think D should really have a friendlier interface to stack-based data str= uctures than just alloca() (unless it already does and I don&#39;t know abo= ut it).<br> <br> Some features which I think would be helpful:<br> - An &quot;automatic&quot; array-like structure entirely on the stack that = starts out with a capacity given by the user), and which switches to the he= ap if it gets too big.<br> - A function that can just allocate a structure easily on the stack, taking= care of constructors and whatnot... something like alloca!Foo() to allocat= e Foo on the stack, and alloca!Foo(5) to allocate Foo[] with a length of 5 = on the stack (NOT Foo[5], obviously...), etc.<br> <br> How does this sound?<br></blockquote><div><br></div><div><a href=3D"http://= d-programming-language.org/phobos/std_typecons.html#scoped">http://d-progra= mming-language.org/phobos/std_typecons.html#scoped</a></div></div><br> --0016e6d27cc9d51ecf04a9d0b81a--
Aug 05 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday 05 August 2011 23:35:58 Mehrdad wrote:
 I think D should really have a friendlier interface to stack-based data
 structures than just alloca() (unless it already does and I don't know
 about it).
 
 Some features which I think would be helpful:
 - An "automatic" array-like structure entirely on the stack that starts
 out with a capacity given by the user), and which switches to the heap
 if it gets too big.

static arrays are always on the stack, but you can't change their size. To do what you're asking, you'd need to essentially have a struct which wrapped a static array and treated its length as its capacity instead of its length, keeping track of the number of elements separately. Then, if you got too many elements, it would reallocate it the heap. But it would still be using all of that memory on the stack, and if it has much size to it at all, it could get expensive to pass it to other functions. It's doable, but I don't see much point to it honestly.
 - A function that can just allocate a structure easily on the stack,
 taking care of constructors and whatnot... something like alloca!Foo()
 to allocate Foo on the stack, and alloca!Foo(5) to allocate Foo[] with a
 length of 5 on the stack (NOT Foo[5], obviously...), etc.

structs are on tha stack already. There's no need to do anything special for that. And if you want a class on the stack, you use std.typecons.scoped (though honestly, I wouldn't generally advise doing that - if you really need to do that, there's a good chance that it should have been a struct in the first place; passing it to other functions becomes dangerous and you generally have to be very careful with classes on the stack). - Jonathan M Davis
Aug 06 2011
parent Mehrdad <wfunction hotmail.com> writes:
On 8/5/2011 11:56 PM, Andrew Wiley wrote:
 On Fri, Aug 5, 2011 at 11:35 PM, Mehrdad <wfunction hotmail.com 
 <mailto:wfunction hotmail.com>> wrote:

     I think D should really have a friendlier interface to stack-based
     data structures than just alloca() (unless it already does and I
     don't know about it).
     [...]

 http://d-programming-language.org/phobos/std_typecons.html#scoped

Allocates a *class* object? I just need an array of e.g. chars... On 8/6/2011 12:00 AM, Jonathan M Davis wrote:
 static arrays are always on the stack, but you can't change their size.

as I already mentioned with the big "NOT". :\
 To do what you're asking, you'd need to essentially have a struct which
wrapped a static array and treated its length as its capacity instead of its
length, keeping track of the number of elements separately. Then, if you got
too many elements, it would reallocate it the heap.

ugly and tedious mixin().
 But it would still be using all of that memory on the stack

 and if it has much size to it at all, it could get expensive to pass it to
other functions.

 It's doable, but I don't see much point to it honestly.

When you **know** that most inputs are going to be minuscule (e.g. file names, only on the order of like ~10 characters on average) and you need to copy them to perform small manipulations, there's **no reason** to invoke a heap allocation unless you actually need it. All I'm asking (for part 1) is that the /INTERFACE/ to alloca() (which /already exists/) be nicer (i.e. return T[] instead of void*), e.g. the user shouldn't be forced to say auto arr = (cast(int*)alloca(len * int.sizeof))[0 .. len]; //Now worry about default values for dchar, etc... every time, when he could just say auto arr = alloca!int(len); instead. Part 2 is just extending the idea by making an array even easier to use (i.e. a struct that holds the array and creates a new array on the heap if it overflows). In fact, it doesn't even have to apply to stack-based arrays -- it could apply to *any* modifiable buffer. I just think it would be especially useful in this context. That's not too unreasonable, is it?
Aug 06 2011
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Mehrdad:

 - An "automatic" array-like structure entirely on the stack that starts 
 out with a capacity given by the user), and which switches to the heap 
 if it gets too big.

See (I will have to add one more answer in this enhancement request): http://d.puremagic.com/issues/show_bug.cgi?id=5348
 - A function that can just allocate a structure easily on the stack, 
 taking care of constructors and whatnot...

This is (will be) in Phobos.
 How does this sound?

Variable-length stack-allocated arrays are very useful in a system language (if they are a little smarter than C VLA then it's better). In Ada many arrays are allocated like this, and this helps performance, also reducing the pressure on the GC. Bye bearophile
Aug 06 2011