Re: [boost] [C++0x] Emulate C++0x char16_t, char32_t, std::u16string, and std::u32string

Subject: Re: [boost] [C++0x] Emulate C++0x char16_t, char32_t, std::u16string, and std::u32string
From: Artyom Beilis (artyomtnk_at_[hidden])
Date: 2011-07-20 18:12:08

----- Original Message ----
> From: Beman Dawes <bdawes_at_[hidden]>
> To: Boost Developers List <boost_at_[hidden]>
> Sent: Wed, July 20, 2011 11:27:38 PM
> Subject: [boost] [C++0x] Emulate C++0x char16_t, char32_t, std::u16string, and 
>std::u32string
> 
> I'm starting to fold in Boost.Filesystem support for the new C++0x
> character  types. Support is emulated for compilers and standard
> libraries not currently  supporting the 0x features. The emulation is
> working fine, with tests passing  on Windows for GCC 4.5 and 4.6, and
> VC++ 8, 9, and 10. Haven't tested on  non-Windows systems yet.
> 
> This is the same emulation approach Microsoft  ships in VC++ 10.
> 
> It seems to me that all Boost libraries that want to  emulate these 0X
> features should use the a unified approach. Otherwise we  could get
> into a situation where libraries A and B worked fine in isolation,  but
> had symbol or ODR clashes when used together.
> 
> The header I'm using  is attached. I propose to place this in
> <boost/string_0x.hpp> rather  than, say,
> <boost/filesystem/detail/string_0x.hpp>, and providing a  simple doc
> page.
> 
> Does this make sense?
> 
> --Beman
>

No, you can't emulate them.

Emulation of char16_t/char32_t is useless for any real use.

You can't create working 

  std::basic_ostringstream<char16_t> stream;

Because stream << 1245 would not work due to lack of std::locale facets.

You can't create requires facets as for example they are specialized
in many standard libraries.

Even existing Microsoft's VC2010 does not work if you compile application
with /MD or /MDd

Note: char, wchar_t, char16_t and char32_t are much more then basic types
that can be distinguished, they bring character information with them.

If you want to represent a UTF-16 or UTF-32 code unit just use uint16_t 
or uint32_t, like for example ICU does for UChar and Qt does for QChar,
but this isn't something that suppose to work with standard library
in place where characters exists.

Also for File system? Please, don't try make it more complicated then it
is now.

You want to make boost.filesystem better? Make it use UTF-8 on Windows
by default and drop all "wide-crap" (sorry windows users).

All operating systems around (with one exception) use char * API and
one operating system uses utf-16/wchar_t API.

So adding arbitrary character that no operating system uses seems
to be waste of effort.

I **personally** don't see any benefit in adding char16_t/char32_t emulation
to the Boost and specialty to the Boost.Filesystem.

Today Boost.Filesystem has enough problems besides char16_t/char32_t.

 Artyom Beilis
--------------
CppCMS - C++ Web Framework:   http://cppcms.sf.net/
CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/