On 10/20/2013 12:23 PM, bearophile wrote:
Walter Bright:
If your optimizing compiler is that good, it can optimize "new T[n]" to be on
the stack as well.
That's escape analysis,
Yes, I know :-)
and it returns a failure as soon as you return the
array, unless you also analyze the caller, and allocate in the caller stack
frame, but this can't be done if the length of the array is computed in the
middle of the called function.
Yes. I know you don't believe me :-) but I am familiar with data flow analysis
and what it can achieve.
Another problem is that D newbies and normal usage of D tends to stick to the
simplest coding patterns. Your coding pattern is bug-prone even for you
I haven't had bugs with my usage of it.
and it's not what programmers will use in casual D code. Stack allocation of
(variable
sized) arrays should become much simpler, otherwise most people in most cases
will use heap allocation. Such allocation is not silent, but it's not better
than the "silent heap allocations" discussed above.
Of course, if you're in a recursive function, stack allocated dynamic arrays
can have unpredictable stack overflow issues.
Unless you are using a segmented stack as Go or Rust.
Segmented stacks have performance problems and do not interface easily with C
functions. Go is not known for high performance execution, and we'll see about Rust.
The technique I showed is also generally faster than dynamic stack allocation.
Do you have links to benchmarks?
No. But I do know that alloca() causes pessimizations in the code generation,
and it costs many instructions to execute. Allocating fixed size things on the
stack executes zero instructions.
