Subject: Re: [boost] [general] What will string handling in C++ look like in the future [was Always treat ... ]
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-01-19 16:04:06
At Wed, 19 Jan 2011 12:50:17 -0800 (PST),
> Most of existing projects and frameworks had decided
> about 1 single and useful encoding:
> - C++:
> + Qt UTF-16 using QString
> + GtkMM UTF-8 using ustring
> + MFC UTF-16 using CString /when compiled in "Unicode mode"
> + ICU UTF-16 using UnicodeString
> - C:
> + Gtk UTF-8 string
> - Java: UTF-16 String
> - C#: UTF-16 string
> - Vala: UTF-8 String/using "char *"
> And so on...
> If you take a look on All C++ frameworks they
> all have a way to convert their string to std::string
> and backwards.
> C++ hadn't picked yet, but C++ has string
> and very good one.
I guess whether std::string is a good design could be considered a
matter of opinion.
> And every existing project has an interface to it.
> The problem we hadn't decided about its encoding.
> Yes, we can't say to standard std::string is UTF-8
> but we can say other things.
> As standard deprecated auto_ptr (which I think is crime but this
> is other story) it should deprecate all non-unicode
> aware uses of std::string and say default is UTF-8.
The standard can't deprecate usage patterns, just language (which
includes the standard library) features.
> Boost can and **should** decide - we use Unicode - and
> we use UTF-8 as all frameworks did.
Except for all the UTF-16 frameworks you cited above?
> Decide and cut it.
> As Boost had decided not to use tabs in source code or use BSL for
> all its code base.
Those were easy to do without breaking code.
> This would do only good.
> Sometimes it is bad to support every bad decision
> that was made.
No argument there.
> As many Boost Developers and Users enjoy the
> fact that Boost is in constant evolution so we
> can evolve and decide:
> On windows char */std::string etc is UTF-8
> if you don't agree, don't use Boost.
Yes we can. It would break code, I'm pretty sure. I am not opposed
to breaking code when the benefits are worth it, but in this case I am
not yet convinced that there isn't an equally-good alternative that
doesn't break code. We're still exploring those alternatives.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk