version(ctfe)

[Fawzi Mohamed]

On 2009-10-19 18:19:34 +0200, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> dsimcha wrote:
>> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
>>> Leandro Lucarella wrote:
>>>> Andrei Alexandrescu, el 19 de octubre a las 08:38 me escribiste:
>>>>> For relatively large chunks of memory, the GC keeps a control block.
>>>>> We could add a member size_t requestedSize that keeps the size that
>>>>> was requested with an allocation/reallocation call. The GC can take
>>>>> initiative in overallocating memory and expose primitives such as
>>>>> requestedSize (how much did the program ask for?) and capacity (how
>>>>> much is really allocated?).  With that API, it is possible to
>>>>> implement ~= efficiently.
>>>> That would mean moving the overhead of arrays to the GC, but that overhead
>>>> will be present for *all* objects, arrays or not, so I don't think it will
>>>> be a good idea...
>>> I forgot to mention that ~= would also have a means to communicate the
>>> GC to overallocate. My point is simple: the problem is that slices don't
>>>   store enough info. That info could get in the memory control block.
>> 
>> This is the part of this thread I'm not understanding:  Isn't this info stored
>> already?  The only problem is querying it is slow.  See GC.sizeOf(), 
>> and bug 2900.
>>  (2900 is fixed, but it's still slow, and there's still bug 2093.)  
>> What are you
>> proposing that's different from the status quo?
> 
> Sorry, I got confused a bit: you have the size in the array and you can 
> get the capacity from the GC, just slowly. Let's sleep on this some 
> more, it may not be impossible to find a growth scheme that works fast.
> 
> Andrei

The problem with the current state, apart slow access to the capacity, 
is an ownership problem: which of the possibly multiple slices owns the 
data after the slice? what happens when multiple slices grow?

In some way the current state is the optimal solution with slice=array.
To improve on this the only way is (I think) to have slice!=array, and 
this was basically what T[new] was all about (at least in my 
understanding).

Ownership of data is a difficult problem with arrays, and clearly 
T[new] and slices is more complex than having slice=array, I would be 
tempted to say that on the whole having T[new] (or even a library 
vector type, if T[new] does not improve upon what a library type does), 
might be a good idea.

Fawzi