Subject: Re: [boost] [gsoc] Request Feedback for Boost.Ustr Unicode String Adapter
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2011-08-09 10:54:08
Soares Chen Ruo Fei wrote:
> A while ago I gave some previews of my Unicode String Adapter library
> to the boost community but I didn't receive much feedback. Now that
> GSoC is ending I'd like you all to take a look at my project again and
> provide feedback on the usefulness of the library. Following are the
> links to my project repository and documentation:
>
> GitHub repository: https://github.com/crf00/boost.ustr
> Documentation: http://crf.scriptmatrix.net/ustr/index.html
I think there are probably as many ways to implement a "better" string
as there are potential users, and previous long discussions here have
considered those possibilities at great length. In summary your
proposal is for a string that is:
- Immutable.
- Reference counted.
- Iterated by default over unicode code points.
- Provides access to the code units via operator* and operator->, i.e.
s.begin() // Returns a code point iterator.
s->begin() // Returns a code unit iterator.
I won't comment about the merits or otherwise of those points, apart
from the last, where I'll note that it is not to my taste. It looks
like it's "over clever". Imagine that I wrote some code using your
library, and then a colleague who was not familiar with it had to look
at it later. Would they have any idea about the difference between
those two cases? No, not unless I added a comment every time I used
it. Please let's have an obvious syntax like:
s.begin() // Code points.
s.impl.begin() // Code units.
or s.units_begin() // Code units.
Personally, I don't want a new clever string class. What I want is a
few well-written building-blocks for Unicode. For example, I'd like to
be able to iterate over the code points in a block of UTF-8 data in raw
memory, so some sort of iterator adaptor is needed. Your library does
have this functionality, but it is hidden in an implementation detail.
Please can you consider bringing out your core UTF encoding and
decoding functions to the public interface?
I would also like to see some benchmarks for the core UTF conversion
functions. If you post some benchmarks that decouple the UTF
conversion from the rest of the string class, I will compare the
performance with my own code.
Regards, Phil.