Chad J wrote:
> bearophile wrote:
>> You can see of this as a small DEP :-)
>>
>> Small variable-length arrays allocated on the stack can be somewhat useful
>> in D. They avoid most usages of alloca() and are a bit safer than alloca()
>> because no pointer casting is needed.
>>
>> alloca() gives some performance improvement compared to normal dynamic
>> arrays if the array is small and the function (here bar()) is called many
>> times (I have experimentally seen this in the Levenshtein distance function,
>> that needs to allocate a temporary buffer. If the length of the two input
>> strings is small I use a fixed-sized array as buffer, this improves
>> performance some in code that needs to compute this distance over many small
>> strings. I think a variable-length array is a bit better here. In this
>> situation often Tango adopts the strategy of adding an extra function
>> argument that allows to give a preallocated buffer to a function).
>>
>
> Tango adopting that convention is interesting to me because it seems
> like a convention that could be used very commonly to make things run
> faster. Note that it is more general than alloca: it allows one to
> allocate stack memory in the /caller's/ stack frame.
>
> char[] stringModify( char[] someStr, char[] buffer )
> {
> // Expand the buffer, but only if necessary.
> size_t len = calculateNeededLengthFrom(someStr);
> if ( buffer.length < len )
> buffer = new buffer[len];
>
> // Sometimes you can't calculate the buffer size needed ahead
> // of time, so you figure it out as you go and use the
> // buffer until you run out.
>
> // Do stuff with someStr, putting the result into buffer.
>
> return buffer; // You can do this. buffer is in parent frame.
> }
>
> So, is there any way to allocate memory in the caller's stack frame in D
> right now?
Err, I mean without explicit help from the caller.
> Can an abstraction be made to do this for both the caller and callee without
> a lot of boilerplate?
>
>> ... (btw hijacking ur thread)
>>
>> Bye,
>> bearophile
>
>
> - Chad
