On 19/01/11 02:40, Andrei Alexandrescu wrote:
On 1/18/11 1:58 AM, Steven Wawryk wrote:
On 18/01/11 16:46, Andrei Alexandrescu wrote:
On 1/17/11 9:48 PM, Michel Fortin wrote:
This makes me think of what I did with my XML parser after you made
code
points the element type for strings. Basically, the parser now uses
'front' and 'popFront' whenever it needs to get the next code point,
but
most of the time it uses 'frontUnit' and 'popFrontUnit' instead
(which I
had to add) when testing for or skipping an ASCII character is
sufficient. This way I avoid a lot of unnecessary decoding of code
points.
For this to work, the same range must let you skip either a unit or a
code point. If I were using a separate range with a call to toDchar or
toCodeUnit (or toGrapheme if I needed to check graphemes), it wouldn't
have helped much because the new range would essentially become a new
slice independent of the original, so you can't interleave "I want to
advance by one unit" with "I want to advance by one code point".
So perhaps the best interface for strings would be to provide multiple
range-like interfaces that you can use at the level you want.
I'm not sure if this is a good idea, but I thought I should at least
share my experience.
Very insightful. Thanks for sharing. Code it up and make a solid
proposal!
Andrei
How does this differ from Steve Schveighoffer's string_t, subtract the
indexing and slicing of code-points, plus a bidirectional grapheme range?
There's no string, only range...
Which is exactly what I asked you about. I understand that you must be
very busy, But how do I get you to look at the actual technical content
of something? Is there something in the way I phrase thing that you
dismiss my introductory motivation without looking into the content?
I don't mean this as a criticism. I really want to know because I'm
considering a proposal on a different topic but wasn't sure it's worth
it as there seems to be a barrier to getting things considered.
