Re: [boost] [general] What will string handling in C++ look like in the future [was Always treat ... ]

Subject: Re: [boost] [general] What will string handling in C++ look like in the future [was Always treat ... ]
From: Alexander Lamaison (awl03_at_[hidden])
Date: 2011-01-20 10:43:52

On Thu, 20 Jan 2011 09:33:02 -0500, Chad Nelson wrote:

> 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.

I imagine you wouldn't have UTF-16 and UTF-32 string being passed about as
a matter for course.  For instance, a UTF-16 string should only be used
just before calling a Windows API call.  

If this is the case, it makes sense to make the common case (UTF-8 string)
have a nice name like boost::string and the others which are used for
special situations can have something less snappy like boost::u16string and
boost::u32string.

Alex

-- 
Easy SFTP for Windows Explorer (http://www.swish-sftp.org)