Boost logo

Boost :

Subject: Re: [boost] [UTF String] Feedback on UTF String library, please
From: Vlad Lazarenko (vlad_at_[hidden])
Date: 2011-02-11 13:24:06

On Fri, Feb 11, 2011 at 12:44 PM, Chad Nelson

> 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
> >> <>: would
> >> those interested in the UTF String library please comment on the new
> >> version?
> >
> > 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.

Unfortunately, users tend not to read documentation. From my experience,
many just using copy-paste
from examples and modify the result to fit their needs. IMHO the default
behavior should be
the fastest from the most safest. But having an example of "tricky" usage to
performance with the explanation of pros and cons will help some users to
copy-paste from the right
place and read documentation before they do so.

> > 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.
> *
> *
> *
> _______________________________________________
> Unsubscribe & other changes:

*Vlad Lazarenko*
* <>*
vlad_at_[hidden] <>

Boost list run by bdawes at, gregod at, cpdaniel at, john at