More on C++ stack arrays

[Walter Bright]

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.