Re: [Boost-bugs] [Boost C++ Libraries] #8369: Do not compile even trivial UTF16 and UTF32 tests with libc++

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #8369: Do not compile even trivial UTF16 and UTF32 tests with libc++
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2013-04-02 19:57:38

#8369: Do not compile even trivial UTF16 and UTF32 tests with libc++
---------------------------+------------------------------------------------
  Reporter:  apolukhin     |       Owner:  apolukhin                                         
      Type:  Tasks         |      Status:  new                                               
 Milestone:  Boost 1.54.0  |   Component:  lexical_cast                                      
   Version:  Boost 1.52.0  |    Severity:  Cosmetic                                          
Resolution:                |    Keywords:  char16_t char32_t unicode utf16 utf32 libc++ clang
---------------------------+------------------------------------------------

Comment (by apolukhin):

 Replying to [comment:1 marshall]:
 > Additional information:
 >
 > The C++ standard (I looked at n3216) specifies (in 22.3.1.1.1) that
 `numpunct<char>` and `numpunct<wchar_t>` are required, and does not
 mention `numpunct<char16_t>` or `numpunct<char32_t>` at all.

 Yes, they are not required, which makes a lot of troubles when
 `std::basic_istream` and `std::basic_ostream` classes are used with those
 character types as template parameters (users miss this functionality, see
 [http://stackoverflow.com/questions/13534639/xcode-4-5-2-libc-stdbad-cast-

 when-implementing-custom-stringstream 1],
 [http://stackoverflow.com/questions/12229900/what-to-replace-

 stdstringstream-and-boostformat-with-for-stdu16string 2]).

 > gcc (I checked version 4.8) provides a completely templated
 implementation of `std::numpunct`, so it supports specializing on any
 character type. libc++ provides two implementations: one for `char` and
 the other for `wchar_t`.

 GCC-4.7 was also providing a fully templated version. Unfortunately, some
 support from glibc was required, so usage of std::numpunct<char16_t> was
 leading to segmentation faults (though have not checked it for a year, may
 be things changed).

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/8369#comment:3>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.