On Wed, Jul 20, 2011 at 4:45 PM, Antony Polukhin <antoshkka@gmail.com> wrote:
2011/7/21 Beman Dawes <bdawes@acm.org>:
This is the same emulation approach Microsoft ships in VC++ 10.
It is a bad approach, and will produce a lot of future workarounds. We can still remember wchar_t as a typedef for some compilers and a BOOST_NO_INTRINSIC_WCHAR_T macro for that defect.
However some emulation for char16_t, char32_t types is required, but it must not be a typedef!
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.
Totally agree.
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.
Agree, but please, don't implement char16_t, char32_t as a typedef!
There is no choice, unless I'm missing something. Microsoft has already taken that approach to emulation, so that cat out of the bag. You can also define BOOST_NO_STRING_0X_EMULATION and turn it off, if you would rather not have emulation. --Beman