On Monday, 15 September 2014 at 02:26:19 UTC, Andrei Alexandrescu
wrote:
So, please fire away. I'd appreciate it if you used RCString in
lieu of string and note the differences. The closer we get to
parity in semantics, the better.
Thanks,
Andrei
***Blocker thoughts***
(unless I'm misunderstood)
- 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).
- 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...)
- 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.
Did I miss something? It seems actually *doing* something with an
RCString is really difficult.
***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).
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" ?
