On Wed, 19 Jan 2011 14:23:25 +0100 Matus Chochlik <chochlik@gmail.com> wrote:
On Wed, Jan 19, 2011 at 2:07 PM, Chad Nelson <chad.thecomfychair@gmail.com> 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 form).
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. * * *