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
