Boost logo

Boost :

Subject: Re: [boost] [string] proposal
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2011-01-27 04:38:16


> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk