
At Wed, 19 Jan 2011 11:33:02 +0100, Matus Chochlik wrote:
The string-encoding-related discussion boils down for me to the following: What fill the string handling in C++ look like in the (maybe not immediate) future.
*Scenario A:*
We will pick a widely-accepted char-based encoding that is able to handle all the writing scripts and alphabets that we can think of, has enough reserved space for future additions or is easily extensible and use that with std::strings which will become the one and only text string 'container' class.
All the wstrings, wxString, Qstrings, utf8strings, etc. will be abandoned. All the APIs using ANSI or UCS-2 will be slowly phased out with the help of convenience classes like ansi_str_t and ucs2_t that will be made obsolete and finally dropped (after the transition).
*Scenario B:*
We will add yet another string class named utf8_t to the already crowded set named above. Then:
library a: will stick to the ANSI encodings with std::strings It has worked in the past it will work in the future, right ?
library b[oost]: will use utf8_t instead and provide the (seamles and straightforward) conversions between utf8_t and std::string and std::wstring. Some (many but not all) others will follow
library c: will use std::strings with utf-8 ... library [.]n[et]: will use String class ... library q[t]: will use Qstrings .. library w[xWidgets]: will use wxStrings and wxChar* library wi[napi]: will use TCHAR* ... library z: will use const char* in an encoding agnostic way
Now an application using libraries [a..z] will become the developers nightmare. What string should he use for the class members, constructor parameters, who to do when the conversions do not work so seamlesly ?
Also half of the cpu time assigned to running that application will be wasted on useless string transcoding. And half of the memory will be occupied with useless transcoding-related code and data.
*Scenario C:*
This is basically the status quo; a mix of the above. A sad and unsatisfactory state of things.
*Scenario D:* We try for scenario A. and people still use Qstrings, wxStrings, etc. *Scenario E:* We add another string class and everyone adopts it -- Dave Abrahams BoostPro Computing http://www.boostpro.com