Hi
Artyom,
So _if_ any supported locale can handle characters outside of BMP, the implementation will qualify as non-conforming according to this paragraph. I know that windows OS itself can handle such characters, so I'd expect supported std locales to be able to handle them as well, but I haven't checked that.
Any clarification on this matter would be appreciated.
I was talking about **codecvt facet only** i.e. conversion via imbue locale to file stream - and this is due to limitation of definition of codecvt facet thats it. Direct conversion functions like to_utf/from_utf has no this limitation. All Boost.Locale support wide characters and it supports characters outside of BMP for UTF-16 encoded strings. If it wasn't it was absolutely useless software. So don't worry... As matter of fact Boost.Locale supports: - narrow (normal) characters - char for 8 bits locale like ISO-8859-8. - narrow (normal) characters - char for variable length locale like UTF-8 or even Shift-JIS. - wide characters wchar-t for both UTF-16 (Windows) and UTF-32 (POSIX) encodings. - C++0x char16_t/char32_t for utf-16/utf-32 if available And of course the support is of all Unicode from 0 to 10FFFF. Everything is fully supported. Only issue that exists if codepage conversion via standard std::loclae::codecvt facet due to its limitation. And BTW I do not recommend use it widely as it has some other issues as well. Best, Artyom