Subject: Re: [boost] [General] Always treat std::strings as UTF-8
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2011-01-19 08:52:10
On Wed, 19 Jan 2011 14:23:25 +0100
Matus Chochlik <chochlik_at_[hidden]> wrote:
> On Wed, Jan 19, 2011 at 2:07 PM, Chad Nelson
> <chad.thecomfychair_at_[hidden]> wrote:
>> There wouldn't be any need for special string types for them. They
>> would be represented by native_t if the system is set to use them,
>> and std::string types would just be assumed to be coded in that form.
> Yes, My point was that there is no need to create ascii_string,
> jis_string and ebcdc_string in the first place but to handle the
> conversion during the initialization of
> the-one-and-only-string-type-we-decide-to-use. :)
You'll get no argument against that from me. :-) But at least two utf*_t
types will be useful even after that conversion: utf8_t (because it
will automatically catch any encoding problems, including malicious
ones), and utf16_t (because the Windows API requires its data in that
>>> One of the downsides is that C++ would be abandoning a nice name
>>> 'string' to ugly 'utf8_t' or whatever.
>> Believe it or not, you'd get used to it. :-) I thought wchar_t was
>> the height of ugliness when I first saw it, but it seems perfectly
>> acceptable now, even attractively descriptive.
> Yes, probably I would. But try to imagine that you are a novice who
> decides which language to learn. Would you pick a language that has 3
> (provided the utf8_t becomes standard) standard string related
> classes not to mention all those dozens of classes implemented by
> various libraries ?
A novice isn't likely to pick C++ regardless. My nine-year-old nephew
wanted to learn programming recently, and despite my own enthusiasm for
C++, I had to recommend he start with Python -- he's plenty smart enough
to dive directly into C++, but the learning curve would be a lot
steeper, and the string-type problem is only one of the issues.
-- Chad Nelson Oak Circle Software, Inc. * * *
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk