These aren't try functions as they succeed in general (unless you are out of memory after conversion policy update) and returing char */wchar_t* makes code shorter.
They will fail if the user-provided buffer isn't big enough.
I see. If some I'd rather expect to extend the boost.locale functionality rather boost.nowide - it seems to be more appropriate (since nowide functions finally call utf_to_utf functions from boost.locale library) Regarding iterator input/output interface. I must say that iterator based interface isn't right for encoding conversions. There was a long discussion regarding it during Boost.Locale review. The major reason is that you don't work on characters by themselves but rather character sequences and intermediate states. Since all conversion API gets some kind of "char *" and virtually every string class around has its "c_str()" variant I don't really see it necessary to provide arbitrary iterators (especially since under the hood I'll need to combine them into chunks of char * for processing) And if you want to process a stream you will be much better going with std::codecvt facet that works on chunks and stream.
What it does it uses native console Wide API to write/read to/from console:
http://cppcms.com/files/nowide/html/index.html#technical_cio
In case of redirection it just becomes alias of std::cin/cout (docs need to be updated a little)
OK. How about mixing use of the boost::nowide:: and the std:: versions? If that possible? Because that's something that I guess will be hard to avoid.
Shouldn't be a problem. Finally all goes to console. Artyom