On Saturday, 1 August 2020 at 16:04:01 UTC, Steven Schveighoffer
wrote:
On 7/31/20 12:32 PM, wjoe wrote:
On Friday, 31 July 2020 at 04:28:57 UTC, Ali Çehreli wrote:
Another option, which is curiously said to be more performant
in memory allocation than native arrays, is
std.array.Appender. I'v
On 31.07.20 06:28, Ali Çehreli wrote:
On 7/30/20 4:42 PM, wjoe wrote:
> So .capacity can't be assigned a value like length to reserve the RAM ?
Yes, a read-only property...
>> auto a = b;
>> b = b[0 .. $-1];
>> b ~= someT;
>>
>> If that last line is done in-place, then it overwrites a[$-
On 7/31/20 12:32 PM, wjoe wrote:
On Friday, 31 July 2020 at 04:28:57 UTC, Ali Çehreli wrote:
Another option, which is curiously said to be more performant in
memory allocation than native arrays, is std.array.Appender. I've used
function-local static Appenders to cut down on memory allocation.
On Friday, 31 July 2020 at 04:28:57 UTC, Ali Çehreli wrote:
Yes but the "sharing being terminated" phrase was my attempt at
explaining things, which did not catch on. :)
Real shame. I quite like it - especially if you say it out loud
with an Austrian accent :)
Another option, which is curio
On 31.07.20 01:42, wjoe wrote:
I could swear just a few weeks ago there was someone asking how to tell
if an array was null or of length 0 and an answer was that it's the same
and can't be distinguished so I assumed that assigning a slice of 0
length is the same as setting the array to null bec
On 7/30/20 4:42 PM, wjoe wrote:
> So .capacity can't be assigned a value like length to reserve the RAM ?
Yes, a read-only property...
>> auto a = b;
>> b = b[0 .. $-1];
>> b ~= someT;
>>
>> If that last line is done in-place, then it overwrites a[$-1].
>
> So this is a case of sharing being te
On Thursday, 30 July 2020 at 16:33:22 UTC, Ali Çehreli wrote:
On 7/30/20 8:58 AM, wjoe wrote:
b.reserve(n);
b.length = n;
There may be something that I don't know but I think assigning
to the .length property alone should be the same as reserving
and then assigning.
rese
On Thursday, 30 July 2020 at 15:58:28 UTC, wjoe wrote:
I just stumbled upon code like this:
struct Foo(T)
{
T[] b;
this(int n)
{
b.reserve(n);
b.length = n;
}
}
.reserve looks redundant.
The docs are explaining .length nicely, however lack any
specifics about
On 7/30/20 11:58 AM, wjoe wrote:
I just stumbled upon code like this:
struct Foo(T)
{
T[] b;
this(int n)
{
b.reserve(n);
b.length = n;
}
}
..reserve looks redundant.
It is, in this case. Reserve will extend the allocated length to n, but
not adjust the
On 7/30/20 8:58 AM, wjoe wrote:
b.reserve(n);
b.length = n;
There may be something that I don't know but I think assigning to the
.length property alone should be the same as reserving and then assigning.
reserve is supposed to make sure no memory will be allocated as elem
I just stumbled upon code like this:
struct Foo(T)
{
T[] b;
this(int n)
{
b.reserve(n);
b.length = n;
}
}
.reserve looks redundant.
The docs are explaining .length nicely, however lack any
specifics about reserve.
Changing the length of an array may relocate
11 matches
Mail list logo
