[boost] Re: Re: Draft Critique of Code Conversion Proposal (N1683)

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-01-07 03:05:33

"Jonathan Turkanis" <technews_at_[hidden]> wrote in message 
news:crl0i9$7mk$1_at_sea.gmane.org...
| Jonathan Turkanis wrote:
|
| > 4. Thorsten asks why the widening and narrowing functions shouldn't be
| > non-member functions. One answer is that code conversion can be
| > (slightly) more efficient if a large buffer is used. Making the core
| > conversion functions member functions allows buffers to be used for
| > several string conversions.
|
| Hmmm ... This is true, but unfortunately doesn't apply to the version I 
posted.
|
| To take advantage of a large buffer, the input would have to be presented in 
a
| manner that gives the implementaion access to underlying characters arrays.
| (This would be the case if, e.g., the input were basic_strings, so that 
data()
| could be used, or if there were a standard iterator category 'Contiguous
| Traversal': http://tinyurl.com/4wynl.)
|
| I think the added flexibility of the overloads taking iterators is more
| significant than the ability to buffer.

I can't really figure out how this buffering should work. Buffering of what?

 I agree that there should be iterator versions underneith the  range 
interface
(that's how it all works.)

Jonathan:
|    template<typename WideStr>
|    basic_string<typename Codecvt::extern_type>
|    narrow(const WideStr& str)
|    {
|          string_converter<> cvt;
|          return cvt::narrow(str);
|    }

The could be specified as

template< class NarrowString, class ReadableWideForwardRange, class Codecvt >
NarrowString narrow( const ReadableWideForwardRange& r,  const Codecvt& cc );
...
utf8_codecvt_facet<char_t> cc;
wstring w1 = L"bar";
string s1 = std::narrow<string>( L"foo", cc );
string s2 = std::narrow<string>( make_iterator_range( w1, w1 + 2 ), cc );
vector<char> s3 = std::narrow<vector<char> >( w1, cc );

Beman:
| > Preferable, the template parameter is just
| >a ForwardRange FR with the requirement that a specialixation
| >of std::char_traits exists for range_value<FR>::type.
|
|There are a lot of ways to redesign the interface. But if too many violent
|changes are made we are no longer talking about existing practice and it
|gets messy to try to convince the LWG. Anyone who wants to can propose an
|alternative to the committee, but my guess is that it would have to be
|dramatically better to have much chance.

Well, we haven't talked about N1683 yet. :-)

-Thorsten