If T[new] is the container for T[], then what is the container for T[U]?
Robert Jacques
sandford at jhu.edu
Sat Apr 25 09:43:48 PDT 2009
On Sat, 25 Apr 2009 11:57:25 -0400, dsimcha <dsimcha at yahoo.com> wrote:
> == Quote from Robert Jacques (sandford at jhu.edu)'s article
>> On Sat, 25 Apr 2009 09:16:39 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>> > Stewart Gordon wrote:
>> >> Andrei Alexandrescu wrote:
>> >>> It looks we can't make it with only T[]. We need a genuine container
>> >>> type, and T[new] was suggested.
>> >> <snip>
>> >> What do you mean by a "genuine container type"?
>> >
>> > One with capacity and probably value semantics.
>> >
>> > Andrei
>> First, capacity is only static (i.e. can be included in the array as you
>> suggest) for free-list based allocation. Which is _only_ used by malloc
>> and mark-sweep GCs. And I'm really hoping Leandro gives us something
>> better than mark-sweep.
>
> But in a pointer bumping GC, the right way to do dynamic arrays would be
> to
> allocate some extra space for the array beyond the length requested, to
> allow it
> to be appended to without being reallocated. In this case, the extra
> space is
> being allocated under the hood by the array functions, not the garbage
> collector,
> but it's still there and you still need a capacity field to track it
> without
> expensive GC queries.
1) There are multiple types of pointer bumping GCs and checking/exending
an array can be pretty darn cheap. (You only have to find the memory page)
2) Pointer bumping is only half a GC, generally the other half is going to
move/compact the array, at which point the capacity *should* be changed.
3) Over-allocating all arrays is a wonderful waste of memory and
performance (re chache lines, etc). A cleaner answer is an array builder
class, which only pays for this overhead when it's actually needed.
More information about the Digitalmars-d
mailing list