
On Tue, Jan 18, 2011 at 8:53 PM, Robert Ramey <ramey@rrsd.com> wrote:
Just a thought.
That instead of the currently used 2 string classes you'll end up with N string classes. That thought is not very appealing to me.
I don't think that's a fair statement. The above only has 4 and that's including EBCDIC.
But those four are not the only widespread encoding schemes, what about KOI8, CPXYZ, etc.
Sorry, I don't get the "2" above.
I meant std::string and std::wstring which contains one string class too many IMO.
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.