On Sunday, 20 October 2013 at 18:42:06 UTC, Walter Bright wrote:
If your optimizing compiler is that good, it can optimize "new T[n]" to be on the stack as well.
Just a side note: LDC actually does this if it can prove statically that the size is bounded. Unfortunately, the range detection is rather conservative (unless your allocation size turns out to be a constant due to inlining, LLVM is unlikely to get it).
One idea that might be interesting to think about is to insert a run-time check for the size if an allocation is known not to be escaped, but the size is not yet determined. As a GC allocation is very expensive anyway, this probably wouldn't even be much of a pessimization in the general case.
I'm not particularly enamored with the compiler inserting silent copying to the heap - D programmers tend to not like such things.
Well, this is exactly what happens with closures, so one could argue that there is precedent. In general, I agree with you, though.
I use this technique frequently. Allocating a few extra bytes on the stack generally costs nothing unless you're in a recursive function. Of course, if you're in a recursive function, stack allocated dynamic arrays can have unpredictable stack overflow issues.
I also find this pattern to be very useful. The LLVM support libraries even package it up into a nice llvm::SmallVector<T, n> template that allocates space for n elements inside the object, falling back to heap allocation only if that threshold has been exceeded (a tunable small string optimization, if you want).
David
