I know of it, yes. But my library purposely *doesn't* use the standard C++ locale subsystem because it's slow, broken, and inflexible. Nevertheless I want to provide the ability to bridge my library with that system.
I would disagree. It has very interesting basics and very extensible allowing you to carry in one class all culture information and copy it efficiently.
Regardless I intend to allow to define a codecvt facet from any pair of objects modeling the Converter concept; so nothing would prevent someone from writing one or chaining them to do whatever they want, granted it converts between char and char or wchar_t and char, since it seems there is
no way around that one.
[snip]
That way you can also do normalization, case conversion or whatnot with a codecvt facet.
It is not the job of codecvt facet, also you'll find may issues with it, it is not suitable for it. In such case I would suggest that it maybe better to use iostreams like interface. or create additional facet that does normalization and case conversion, don't use codecvt, it is designed for specific purposes. You need facets? Create your own. Also, do you aware of fact that case conversion is locale dependent? So you still need to connect locale somehow.
utf8_codecvt_facet is an utility provided by boost in the detail namespace, that some libraries
not particularly tied to Windows appear to use.
utf8_codecvt_facet is designed to be used by many libraries that want to convert text from wide to narrow format. For example boost.program_options use it for text conversion for thous who needs wide api. Artyom