February 03, 2013 Re: new T[size] vs .reserve | ||||
---|---|---|---|---|
| ||||
Posted in reply to Namespace | 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
|
February 03, 2013 Re: new T[size] vs .reserve | ||||
---|---|---|---|---|
| ||||
Posted in reply to Namespace | 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.
|
February 03, 2013 Re: new T[size] vs .reserve | ||||
---|---|---|---|---|
| ||||
Posted in reply to Era Scarecrow | 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
|
February 03, 2013 Re: new T[size] vs .reserve | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | > In bugzilla there is a preliminary request for better and less bug-prone VLAs for D.
>
> Bye,
> bearophile
Can you link it here?
|
February 03, 2013 Re: new T[size] vs .reserve | ||||
---|---|---|---|---|
| ||||
Posted in reply to Namespace | 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 |
February 03, 2013 Re: new T[size] vs .reserve | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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?
|
February 03, 2013 Re: new T[size] vs .reserve | ||||
---|---|---|---|---|
| ||||
Posted in reply to Era Scarecrow | 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 |
February 05, 2013 Re: new T[size] vs .reserve - alloca | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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.
|
February 05, 2013 Re: new T[size] vs .reserve - alloca | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Treleaven | 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.
|
February 05, 2013 Re: new T[size] vs .reserve - alloca | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Treleaven | 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
|
Copyright © 1999-2021 by the D Language Foundation