Am 02.02.2013 18:40, schrieb Namespace:
> No one said that this is a problem, or? (;
> But why should I generate an array with size 4 if an append of me resize
> it to 5?
That's what reserve is for.

auto bla = new ubate[4];
bla[3] = 1; // valid


ubyte[] bla;
bla.reserve(4);
bla[3] = 1; // invalid

On Sunday, 3 February 2013 at 09:11:59 UTC, Namespace wrote:
> Sure, but alloca has the same ugly interface as malloc. :/

 You mean that you have to specify how many raw bytes you want, then cast it to what you need? I never thought alloca or malloc were that ugly.

Era Scarecrow:

> On Sunday, 3 February 2013 at 09:11:59 UTC, Namespace wrote:
>> Sure, but alloca has the same ugly interface as malloc. :/
>
>  You mean that you have to specify how many raw bytes you want, then cast it to what you need? I never thought alloca or malloc were that ugly.

The interface of alloca() is bug-prone. And it's not handy if you want to create a 2D or nD array on the stack :-) In bugzilla there is a preliminary request for better and less bug-prone VLAs for D.

Bye,
bearophile

> In bugzilla there is a preliminary request for better and less bug-prone VLAs for D.
>
> Bye,
> bearophile

Can you link it here?

Namespace:

>> In bugzilla there is a preliminary request for better and less bug-prone VLAs for D.
>> ...
> Can you link it here?

http://d.puremagic.com/issues/show_bug.cgi?id=5348

Bye,
bearophile

On Sunday, 3 February 2013 at 13:22:53 UTC, bearophile wrote:
> The interface of alloca() is bug-prone. And it's not handy if you want to create a 2D or nD array on the stack :-) In bugzilla there is a preliminary request for better and less bug-prone VLAs for D.

 Maybe. I barely have ever used alloca myself, but glancing over the VLA's it seems iffy. If there's just one it's easy to implement, however if there's several then the data would point to a slice on the stack. I can see how it works in my head, but with dynamic arrays, malloc & scope you can get a similar affect. Hmmm... Maybe a possible use for a template instead?

Era Scarecrow:

> I barely have ever used alloca myself,

I have used alloca less than 10 times in D with DMD, but the performance improvement was well visible.


> Maybe a possible use for a template instead?

I don't know.

Bye,
bearophile

On 03/02/2013 13:22, bearophile wrote:
> Era Scarecrow:
>
>> On Sunday, 3 February 2013 at 09:11:59 UTC, Namespace wrote:
>>> Sure, but alloca has the same ugly interface as malloc. :/
>>
>>  You mean that you have to specify how many raw bytes you want, then
>> cast it to what you need? I never thought alloca or malloc were that
>> ugly.
>
> The interface of alloca() is bug-prone. And it's not handy if you want
> to create a 2D or nD array on the stack :-) In bugzilla there is a
> preliminary request for better and less bug-prone VLAs for D.

^ I know you're aware of this, but maybe others might not know the default-argument alloca wrapping trick:

import std.stdio;
import core.stdc.stdlib:alloca;

T *stack(T)(void* m = alloca(T.sizeof))
{
    return cast(T*)m;
}

void main(string[] args)
{
    auto i = stack!int();
    *i = 5;
    writeln(*i);
    writeln(i);
    int j;
    writeln(&j);
}

More advanced behaviour e.g. switching to heap allocation for large sizes of T may be possible.

On 05/02/2013 16:17, Nick Treleaven wrote:
> On 03/02/2013 13:22, bearophile wrote:
>> Era Scarecrow:
>>
>>> On Sunday, 3 February 2013 at 09:11:59 UTC, Namespace wrote:
>>>> Sure, but alloca has the same ugly interface as malloc. :/
>>>
>>>  You mean that you have to specify how many raw bytes you want, then
>>> cast it to what you need? I never thought alloca or malloc were that
>>> ugly.
>>
>> The interface of alloca() is bug-prone. And it's not handy if you want
>> to create a 2D or nD array on the stack :-) In bugzilla there is a
>> preliminary request for better and less bug-prone VLAs for D.
>
> ^ I know you're aware of this, but maybe others might not know the
> default-argument alloca wrapping trick:

I've just realized this doesn't work for variable-length allocation:

T[] stack(T)(size_t N, void* m = alloca(T.sizeof * N))

Error: undefined identifier N, did you mean alias T?

N is not visible in the caller's scope.

Nick Treleaven:

> ^ I know you're aware of this, but maybe others might not know the default-argument alloca wrapping trick:

For some usages it's an improvement over raw usage of alloca.
I did see this in past, but sometimes I forget.

Bye,
bearophile