Cart
[Home] [By Thread] [By Date] [Recent Entries]
At 10:06 06/12/99 +0100, Steinar Bang <sb@m...> wrote: >After thinking over the weekend, I'm changing my vote on this issue. >I think the convenience of using basic_string<> way outweighs the >cost advantages of lazy conversion, Agreed. >But the UTF-16 string should not be a straight typedef. We should >derive from basic_string<SAXChar> to get a char* constructor that >would take a UTF-8-encoded string. This is for ease of use with >character constants. I disagree with this, though. It's not that much of a hardship to add an "L" before your character constants; certainly not enough to warrant subclassing a class without a virtual dtor (and duplicating all the constructors and all the functions which return a string as a function result). I think I'd go for using straight std::wstring, and define the characters in those wstrings to be UTF-16 encoded (whatever the current C locale says). Leave it up to the application either to set a locale in which wchar_t is UTF-16 (in which case the RTL functions will behave sensibly), or not (in which case the application will have to hand crank some things). -- Cheers, John xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
