On Thu, 23 Apr 2009 19:00:10 -0400, Andrei Alexandrescu
<[email protected]> wrote:
Robert Jacques wrote:
On Thu, 23 Apr 2009 14:37:37 -0400, Andrei Alexandrescu
<[email protected]> wrote:
dsimcha wrote:
CapacityArray: A range that covers a builtin array and gives it a
capacity
field. All operations that don't have to do with appending are
forwarded to
the underlying array via alias this (modulo a few compiler bugs),
meaning that
a CapacityArray has an identical compile time interface to a builtin
array,
and is implicitly convertible to one.
Upon more thinking, I think we'll have to bit the bullet and define
Array!T and Slice!T. Then dmd rewrites:
[ a, b, c ] -> .Array!(typeof(a))(a, b, c)
T[new] -> .Array!(T)
new T[n] -> .Array!(T)(n)
T[] -> .Slice!(T)
It seems increasingly clear that slices alone can't quite cut the
mustard.
So your CapacityArray will essentially be the basis of Array.
No. The capacity field hack only works with the current free-list
based mark-sweep GC. In every other type of GC, the capacity is dynamic
and can not be cached in the array itself. Introducing a language
feature that is specific to an implementation seems like a bad idea.
1. STL does the same thing so it's likely a more general issue than one
might think.
1) Malloc generally uses a free-list based allocation scheme, so no, its
not more general.
2) The STL is a library, not a language feature.
2. This is not a language feature. Different implementations can take
different routes.
Creating seperate types for slices and arrays is a language feature.
P.S. I think having array builders in Phobos is a good idea, I just don't
think that they warrant a language change.
