Re: [boost] [gsoc] Request Feedback for Boost.Ustr Unicode String Adapter

Subject: Re: [boost] [gsoc] Request Feedback for Boost.Ustr Unicode String Adapter
From: Soares Chen Ruo Fei (crf_at_[hidden])
Date: 2011-08-17 05:20:56

On Wed, Aug 17, 2011, Phil Endecott wrote:
>> Well I don't think forcing all generic Unicode algorithms to provide
>> specialization version for forward-only iterators is any better than
>> providing a less-efficient bidirectional iterator. Such a burden is
>> too high for the algorithm developers. Or perhaps a better decision is
>> to simply let the compiler yield a (friendly?) error when the generic
>> algorithm uses the decrement/random access operator, and find a way to
>> inform the user to convert the string to standard UTF strings before
>> passing to the Unicode algorithms.
>
> The "less-efficient" O(N^2) bidirectional iterator is completely
> unreasonable.  Algorithms are not being "forced" to do anything.
>
> Have a look at how the standard library does things.  std::lower_bound() and
> std::rotate(), for example, have specialisations that select different
> algorithms depending on the type of iterator that is supplied; on the other
> hand, std::random_shuffle() only takes random access iterators and it would
> be the user's responsibility to choose what to do if they had some other
> kind of range.
>
>> Or perhaps I could find a way to let template instances of
>> unicode_string_adapter with MBCS encoding to store convert the string
>> to UTF string during construction and store the UTF encoded string
>> instead. The only problem for this is that during conversion back to
>> the raw string, the string adapter would have to reconvert the
>> internally stored UTF-encoded string back to the MBCS-encoded string.
>> This can be expensive if the user regularly wants access the raw
>> string, unless we store two smart pointers within the string adapter -
>> one for the MBCS string and one for the converted UTF string, but
>> doing so would waste storage space as well.
>
> No, don't do that.  Just provide the iterators that can be provided
> efficiently.

Alright thanks for your advice, I'll try to implement it within these
few days. Now I learn something new. :)

Soares