Re:UCS vs. UTF-8 as Internal String Encoding
by TheCoelacanth on Thursday May 28, 2015 @10:30PM
(#9622389)
It only has to be an abstract class if you want to prevent the existence of invalid offsets, but the same is true if you have constant width code points. For instance, INT_MAX is not a valid offset into almost any string.
> It only has to be an abstract class if you want to prevent the existence of invalid offsets
Wouldn't you want that? I would.
> the same is true if you have constant width code points
True, but the validity check for the constant-width case can be done in constant time.
Re:UCS vs. UTF-8 as Internal String Encoding
by TheCoelacanth on Friday May 29, 2015 @09:25AM
(#9624351)
> True, but the validity check for the constant-width case can be done in constant time.
The same is true of UTF-8 because it is self-synchronizing. You only have to check that the byte at the given offset is either 0xxxxxxx or 11xxxxxx.
> Why would you want constant time access to code points?
The answer is: because you might want to compute an offset into a string in one place in your code, and then pass that offset to another place in your code which then accesses the string at that offset in constant time.
My point is that to make this work you must have string offset be an abstract class, not an integer.