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! Best regards, Antony Polukhin