To all discussing about how to create an "ultimate" string, I'd like to remind you following "ultimate" strings existing there:
1. QString:
http://doc.qt.nokia.com/latest/qstring.html
2. Glib::ustring:
http://library.gnome.org/devel/glibmm/unstable/classGlib_1_1ustring.html
3. wxString:
http://docs.wxwidgets.org/trunk/classwx_string.html
4. icu::UnicodeString
http://icu-project.org/apiref/icu4c/classUnicodeString.html
5. CString
http://msdn.microsoft.com/en-us/library/ms174288(v=VS.100).aspx
Now Questions: --------------
1. Why do YOU think you'll be able to create something "better"?
2. Why do YOU think boost::string would be adopted in favor of std::string or one of the current widely used QString/ustring/wxString/UnicodeString/CString?
3. What so painful problems are you going to solve that would make it so much better then widely used and adopted std::string? Iterators? Mutability? Performance?
(Clue: there is no painful problems with std::string)
Now Suggestion: ---------------
1. Accept it that there is quite small chance that something that is not std::string would be widely accepted
2. Try to solve existing "string" problems by using same std::string and adding few things to handle it better.
Clue: take a look on what Boost.Locale does.
And we are back at the beginning ... IMO at this point it would be useful if as many people as possible clearly expressed their opinion about this. I basically agree with everything, that Artyom said in this post. We want to create a better string class ? Fine but let us do it in a way that makes it as likely as possible that it would be adopted as the next std::string AND let us also consider the encoding, not only its performance and interface specification. BR, Matus