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-19 13:54:31
> On Wed, 19 Jan 2011 18:41:22 +0100, Matus Chochlik wrote:
> > On Wed, Jan 19, 2011 at 6:21 PM, Alexander Lamaison <awl03_at_[hidden]> wrote:
> >> On Wed, 19 Jan 2011 18:10:06 +0100, Matus Chochlik wrote:
> >> >>
> >> > They made the transition? I must have missed this.
> >> >
> >> > The Windows API _is_ C and has all the problems we've been talking about.
> >> >
> >> OK, besides Microsoft C world :)
> > By changing the OS-default encoding to assume char* string was UTF-8. Same
> > as for C++. This whole issue is about how to accommodate OSses that don't
> > make that assumption.
> Agreed, again if Microsoft could move by default to UTF-8
> for the various locales instead of using the current encodings
> then this whole discussion would be moot.
> For the time being we would need to do something like this
> even if a complete transcoding is not possible:
> std::string filepath(get_path_in_utf8())
> std::fstream file(utf8_to_locale_encoding(filepath));
> everywhere the implementation (STL, etc.) expects native
> encoding. This is the ugliest part of the whole transition.
> Boost could hide this completely by using the wide-char
> interfaces and doing CreateFileW(utf8_to_winapi_wide(filepath), ...).
> It also could be an opportunity for alternate
> implementations of STL which would handle it transparently.
Hmmmm ... I'm starting to come round to your std::string == UTF-8 point-of
The one thing that would still annoy me is that std::string's interface was
clearly designed for single-byte == single-character/codepoint/whatever
operation. I don't suppose anyone will be adding
.begin_character()/.end_character() methods to std::string any time soon.
-- Easy SFTP for Windows Explorer (http://www.swish-sftp.org)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk