LRU cache for ~=

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Mon Oct 19 15:24:38 PDT 2009


dsimcha wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
>> Making ~= work well for slices does not preclude creating a distinct
>> library type.
>> Andrei
> 
> Yes, I see LRU/MRU/whatever as a kludge to allow convenience without being unsafe
> egregiously inefficient.  The fact that it is a kludge is not a criticism because
> there is clearly no easy answer, and thus a kludge is genuinely necessary.
> However, I think there needs to be a separate array builder type for "heavy duty"
> appending operations.  In TDPL I would just say that concatenating slices can be
> inefficient and that people should use array builder for heavy duty appending,
> length changing, etc., w/o getting into the details.

But how about the opposite view. What if the *previous* implementation 
of GC and ~= were a kludge that led to egregious inefficiency and 
revolting unsafety, kludge that that now is getting fixed.

What I'm saying is that with the cache in place we'll have slices that 
are safe and efficient. Right now they are not safe and not efficient. I 
can hardly find reasons to characterize the new state of affairs as kludgey.

One surprising (but safe) behavior that remains with slices is this:

void fun(int[] a) {
    a[0] = 0;
    a ~= 42;
    a[0] = 42;
}

The caller may or may not see 42 in the first slot after the call.


Andrei



More information about the Digitalmars-d mailing list