On 8/24/14, 5:49 AM, "Marc Schütz" <schue...@gmx.net>" wrote:
On Sunday, 24 August 2014 at 12:24:03 UTC, Andrei Alexandrescu wrote:
To that end I'm working on RCString, an industrial-strength string
type that's much like string, just reference counted and with
configurable allocation. It's safe, too - user code cannot casually
extract references to string internals. By default allocation would
use GC's primitives; one thing I learned to appreciate about our GC is
its ability to free memory explicitly, which means RCString will free
memory deterministically most of the time, yet if you leak some (e.g.
by having RCString class members) the GC will pick up the litter. I
think reference counting backed up by a GC that lifts litter and
cycles and is a modern, emergent pattern that D could use to great
effect.
Any reason why this is restricted to strings? I.e., is there something
special about strings (apart from auto-decoding) that doesn't apply to
arrays in general? If not, wouldn't an RCArray be a better idea?
Thanks for asking. Strings are not special, but are a good place to
start because (a) they are ubiquitous so good bang for the buck, (b)
they don't have indirections to worry about, (c) they have a readily
available built-in to compare against. Also RCString is different from
e.g. std.container.Array in that the former has slice semantics whereas
the latter has pure reference semantics.
Andrei
