From: Erik Wien (wien_at_[hidden])
Date: 2004-10-21 19:43:19
"Vladimir Prus" <ghost_at_[hidden]> wrote in message news:cl7kha$tk4
>> That is true. Though the strings of different encodings should be
>> assignable to each other, libraries taking references to encoded_strings
>> would need some conversion to be done.
>> We have a similar problem today with basic_string<char> and
>> basic_string<wchar_t>, and I think it could also be solved in a way that
>> is very similar to what is done in the <string> header.
> Just to clarify: the string and wstring in the standard have a huge
> you can't convert string to wstring in any way: there's just no
> converting constructor.
Correct, and that should be provided if we were to make a unicode_string
templated in encoding. (Not that we neccesarily will.)
>> If we typedef a
>> unicode_string or something as encoded_string<utf16>, and promote that as
>> THE string class, most users would use that as their primary string
>> representation, and simply be oblivious to the underlying encoding. (A
>> good thing.)
> That would still make it easy for a user to use some different encoding
> without good reason.
It would be possible yes, not even difficult, but I don't think that means
people will actually do that. People usually use std::string today, not
basic_string<whatever>, because that is "the string class". I think a
similar thing would happen with a unicode_string typedef. Especially if
there is no difference in the interface between the different template
versions. Then you'd have to know what the differences between the different
encodings are (be an andvanced user, and aware of the drawbacks), to
actually bother using anything other that UTF-16.
>> Advanced user could (just like we do today with basic_string) choose to
>> support multiple encodings by templating their own functions on encoding
>> as well.
> Oh well. I just hope nobody will ever make an implementation of
> XML parser + XML Schema + XPath + XQuery + SOAP + HTML renderer
> which is fully templated on string type, unless the same person speeds up
> gcc by 10 times previously.
Point taken. ;)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk