--------------------------------------------
On Thu, 10/8/15, Peter Dimov
I agree that this makes the most sense. I only brought up <codecvt> because if we used the standard interface and names we wouldn't have needed a full review of the hypothetical libs/codecvt.
See... lots of stuff in standard library related to Unicode is broken. It wasn't fixed in C++11 and wouldn't be later. Also there is deep problem with Windows API that created Wide API and ignores any standard - both C and C++. i.e.. there are basic files that can't even be opened on Windows using plain C fopen or C++ std::fstream.
As this stands, libs/utility seems the best bet, although I'm not overly fond of the practice of putting everything that doesn't fit elsewhere into Utility. :-) But it's better than Detail because it's documented and tested. One could make the case for libs/utf8 which would contain utf8_facet and the "obvious"
bool is_valid_utf8( string const & s ); wstring utf8_decode( string const & s ); string utf8_encode( wstring const & s );
but this is already well into full review/bikeshed territory.
See, all this is already implemented in header only way in Boost.Locale - so no linking required.
https://github.com/boostorg/locale/blob/master/include/boost/locale/utf.hpp
https://github.com/boostorg/locale/blob/master/include/boost/locale/encoding...
So just call boost::locale::conv::utf_to_utf