Escaping the Tyranny of the GC: std.rcstring, first blood

[Dicebot via Digitalmars-d]

On Friday, 19 September 2014 at 15:09:41 UTC, Andrei Alexandrescu 
wrote:
> It does affect management, i.e. you don't know when to free the 
> buffer if slices are unaccounted for. So the design of slices 
> are affected as much as that of the buffer.

I see where you are going at. A bit hard to imagine how it fits 
the big picture when going bottom-up though but I trust you on 
this :)

>> I agree that pipeline approach does not work that well for 
>> complex
>> programs in general but strings seem to be best match to it - 
>> either you
>> want read-only access or a pipe-line, everything else feels 
>> inefficient
>> as amount of write operations gets out of control. Every 
>> single attempt
>> to do something clever with shared CoW strings in C++ I have 
>> met was a
>> total failure.
>
> What were the issues?

Usually it went that way:

1) Get basic implementation, become shocked how slow it is 
because of redundant reference increments/decrements and thread 
safety
2) Add speed-up hacks to avoid reference count amending when 
considered unnecessary
3) Get hit by a snowball of synchronization / double-free issues 
and abandon the idea completely after months of debugging.

Of course those weren't teams of rock-star programmers but at the 
same time more "stupid" approach with making extra copies and 
putting extra effort into defining strict linear ownership chain 
seemed to work much better.

>> That is why I wonder - what kind of applications really need 
>> the
>> rcstring as opposed to some generic rcarray?
>
> I started with rcstring because (a) it's easier to lift off the 
> ground - no worries about construction/destruction of elements 
> etc. and (b) it's frequent enough to warrant some good testing. 
> Of course there'll be an rcarray!T as well.


Thanks for explanation :) Well, I am curious how will it turn out 
but a bit skeptical right now.