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

[Andrei Alexandrescu via Digitalmars-d]

On 9/19/14, 3:32 AM, Dicebot wrote:
> On Wednesday, 17 September 2014 at 16:32:41 UTC, Andrei Alexandrescu wrote:
>> On 9/17/14, 9:30 AM, Dicebot wrote:
>>> Ironically, strings have been probably least of my GC-related issues
>>> with D so far - hard to evaluate applicability of this proposal because
>>> of that. What are typical use cases for such solution? (not questioning
>>> its importance, just being curious)
>>
>> Simplest is "I want to use D without a GC and suddenly the string
>> support has fallen down to bear claws and silex stones."
>>
>> RCString should be a transparent (or at least near-transparent)
>> replacement for string in GC-less environments.
>
> Well this is exactly what I don't understand. Strings we have don't have
> any strong connection to GC (apart from concatenation which can be
> verified by @nogc) being just slices to some external buffer. That
> buffer can be malloc'ed or stack allocated, that doesn't really affect
> most string processing algorithms, not unless those try to do some
> re-allocation of their own.

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 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?

> 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.


Andrei