On Tuesday, 6 June 2017 at 09:57:31 UTC, Steven Schveighoffer
wrote:
Note that p[0 .. sz] is treated as an opaque range of memory
assumed to be suitably managed by the caller. In particular,
if p points into a GC-managed memory block, addRange does not
mark this block as live.
Is that paragraph wrong?
No I am wrong. I assumed that because the gc is part of the
static space it's metadata would also be scanned. But the data
is allocated using c malloc, so it's not scanned. This makes
any partial insertion using addrange more dangerous actually
because you have to take care to keep a pointer to that block
somewhere
You mean explicitly pointer to the block itself? It is being kept
with the first array.
Or you mean the pointer passed to addRange? That one would not
necessarily belong to the first array. But I thought the GC does
track pointers that point to block interiors. After all, that's
how slices work.
Then it's just the obvious() function. The whole point of the
exercise is to make one GC allocation instead of N :) But
still GC, so as not to put additional responsibility on the
caller.
No, 2 allocations instead of N.
In this example. But obviously I'd like to make this generic,
i.e.:
struct S { /* ... */ }
auto arrays = allocateArrays!(int, "ints", numInts, S, "Ss",
numSs, void*, "pointers", numPtrs);
So it won't necessarily be 2. And of course the function would
calculate the alignment, initialize the contents (or not, e.g.
via passing a dummy type Uninitialized!T), etc.
I do have a use case for allocating up to 4 arrays at once, for
example.
