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

[Andrei Alexandrescu via Digitalmars-d]

On 9/15/14, 2:50 AM, monarch_dodra wrote:
> - Does not provide Forward range iteration that I can find. This makes
> it unuseable for algorithms:
>      find (myRCString, "hello"); //Nope
> Also, adding "save" to make it forward might not be a good idea, since
> it would also mean it becomes an RA range (which it isn't).

If we move forward with this type, traits will recognize it as isSomeString.

> - Does not provide any way to (even "unsafely") extract a raw array.
> Makes it difficult to interface with existing functions. It would also
> be important for "RCString aware" functions to be properly optimized (eg
> memchr for searching etc...)

I think a @system unsafeSlice() property would be needed indeed.

> - No way to "GC-dup" the RCString. giving "dup"/"idup" members on
> RCstring, for when you really just need to revert to pure un-collected GC.

Nice. But then I'm thinking, wouldn't people think .dup produces another 
RCString?

> Did I miss something? It seems actually *doing* something with an
> RCString is really difficult.

Yah it's too tightly wound right now, but that's the right way!

> ***Random implementation thought:***
> "size_t maxSmall = 23" is (IMO) gratuitous: It can only lead to
> non-optimization and binary bloat. We'd end up having incompatible
> RCStrings, which is bad.
>
> At the very least, I'd say make it a parameter *after* the "realloc"
> function (as arguably, maxSmall  depends on the allocation scheme, and
> not the other way around).

I think realloc will disappear.

> In particular, it seems RCBuffer does not depend on maxSmall, so it
> might be possible to move that out of RCXString.
>
> ***Extra thoughts***
> There have been requests for non auto-decoding strings. Maybe this would
> be a good opportunity for "RCXUString" ?

For now I was aiming at copying string's semantics.


Andrei