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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-01-06 20:30:55

At 04:07 PM 1/5/2005, Thorsten Ottosen wrote:
 >
 >| 1. Hard-wired byte_string type in wstring_convert
 >| -------------------------------------------------
 >|
 >| The underlying wstring_convert design seems flexible enough to cope 
with
 >| conversion between any two character types which meet std::basic_string
 >| requirements. Conversion is actually performed by std::codecvt, which 
is
 >| already parameterized by both internalT and externalT types. It seems
 >| artificial to restrict wstring_convert::byte_string to
 >| std::basic_string<char>. New character types such as the proposed
 >char16_t
 >| and char32_t will need conversions to and from other wide types, yet 
with
 >| the current restriction wstring_convert could not be used for that
 >purpose.
 >|
 >| Suggested change: replace
 >|     typedef std::basic_string<char> byte_string;
 >| with:
 >|     typedef std::basic_string<typename Codecvt::extern_type> 
byte_string;
 >| and change from_bytes argument types accordingly.
 >|
 >| If this suggested change is accepted, it will probably make sense to
 >rename
 >| some wstring_convert members.
 >
 >hm...why not remove the dependency of std::basic_string altogether and 
make
 >it a template parameter.

Jonathan Turkanis' original comment was:

 >(One thing I don't understand is why the character type of 
wbuffer_convert
 >is allowed to be specified as the second template argument. It seems to 
me
 >that the character type should always be equal to Codevt::intern_type.)

But I think that you are closer to the real problem with the proposal; the 
full string type rather than just the character type should be a template 
parameter. That allows any std::basic_string to be used.

 > 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.

Thanks for your comment,

--Beman