alloca() in D

[Mehrdad]

On 8/5/2011 11:56 PM, Andrew Wiley wrote:
> On Fri, Aug 5, 2011 at 11:35 PM, Mehrdad <wfunction at hotmail.com 
> <mailto:wfunction at 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.
Yes, I know - I was specifically ***NOT*** talking about static arrays, 
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.
Yes, that's exactly what I'm already doing in my code, at the cost of an 
ugly and tedious mixin().

> But it would still be using all of that memory on the stack
Omg! I wasted like 16 bytes.

> and if it has much size to it at all, it could get expensive to pass it to other functions.
But it doesn't.

> It's doable, but I don't see much point to it honestly.
That's like saying you don't see a point to alloca()...

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?