Variable-length stack allocated arrays

Chad J chadjoan at __spam.is.bad__gmail.com
Mon Jan 11 16:01:11 PST 2010


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?  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



More information about the Digitalmars-d mailing list