Subject: Re: [boost] [UTF String] Feedback on UTF String library, please
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2011-02-11 12:44:09
On Fri, 11 Feb 2011 17:22:50 +0000
"Phil Endecott" <spam_from_boost_dev_at_[hidden]> wrote:
> Chad Nelson wrote:
>> I reiterate my request from this message
>> <http://permalink.gmane.org/gmane.comp.lib.boost.devel/214601>: would
>> those interested in the UTF String library please comment on the new
> It looks like you've started a new thread in the hope of "throwing
> Mathias off the scent".
More to leave the bad taste of the previous thread behind, for myself
and other potential participants.
> His tone has indeed been unusually aggressive and it would be good to
> get some other peoples' comments - but to me, it looks like he has
> made a fundamentally accurate analysis of your proposal.
Maybe so, I couldn't tell the good feedback from the bad.
> For example, you have this "almost" random-access feature that, IIUC,
> for UTF-8 will give you O(1) random access if you have only ASCII
> characters and for UTF-16 will give you O(1) random access if you
> have only BMP characters. That's just horrible! [...]
If you put it that way, you're right. I assumed that the developer
using the library would read the documentation and know that the
iterators weren't always true random-access, but that assumption
doesn't stand up to conscious examination.
> IMHO, if you want to add these features, they should be done in a way
> that prevents the user from accidentally misusing them. Rather than
> this drop-in replacement for std::string that misbehaves at run time,
> I would prefer something that requires some work to make it fit, but
> then behaves as expected.
Perhaps renaming the current iterator types to "fast_iterator", and
making the standard iterators bidirectional ones? I'd hate to saddle
all UTF strings with only bidirectional iterators when many of them can
use the much faster random-access ones.
-- Chad Nelson Oak Circle Software, Inc. * * *
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk