On Wed, Jan 19, 2011 at 2:07 PM, Chad Nelson <chad.thecomfychair@gmail.com> wrote:
On Wed, 19 Jan 2011 10:26:05 +0100 Matus Chochlik <chochlik@gmail.com> wrote:
But those four are not the only widespread encoding schemes, what about KOI8, CPXYZ, etc.
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. :)
In any case, one could state with Just utf8_string and ansi_string (should be simple), put it into boost and see how many people use it. If it's truely an improvement, usage of std:string would atrophy to the point of being irrelevent. If there are still reasons for using std::string directly, then it wouldn't, but no harm would be done. This has all the upside and none of the downside.
If this were made,
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 ? Best, Matus