Subject: Re: [boost] [general] What will string handling in C++ look like in the future [was Always treat ... ]
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2011-01-20 09:33:02
On Thu, 20 Jan 2011 09:59:51 +0100
Matus Chochlik <chochlik_at_[hidden]> wrote:
>> Do you see another way to provide those conversions, and automatic
>> verification of proper UTF coding? (Automatic verification is a very
>> good thing, without it someone won't use it or will forget to, and
>> open up their programs to exploitation.)
> Yes, implementing it into std::string in some future standard.
'Fraid that's a little beyond my current level of programming skill. ;-)
>>> Besides the ugly name and that is a new class ? No :)
>> If you can think of a more-acceptable-but-still-descriptive name for
>> it, I'm all ears. :-)
> I have an idea: what about boost::string, which could possibly become
> the next std::string in the future.
And string16 and string32? We'll have to support UTF-32, as the
single-codepoint-per-element type, and UTF-16 (distasteful though it
may be) is needed for Windows.
Or are you suggesting the utf* types in addition to the boost::string
type? If so, I believe the idea has merit.
>>> And the solution is long overdue. And creating utf8_t is just
>>> putting the problem away, not solving it really.
>> I see it as merely easing the transition.
> OK, if the long term plan is:
> 1) design and implement boost::string using UTF-8 doing all the things
> like code-point iteration, character iteration, convenience stuff like
> starts-with, ends-with, replace, trim, etc., etc. with as much
> backward compatibility with std::string as possible without hindering
> 2) try really hard to push it to the standard
> then I'm on board with that.
Some of those could be problematic (I've run across references implying
that 0x20 isn't the universal word-separation character, so trim would
at least need some extra parameters), but for the most part, I'd agree
-- Chad Nelson Oak Circle Software, Inc. * * *
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk