On Mon, Jan 23, 2012 at 14:47, Beman Dawes <bdawes@acm.org> wrote:
On Mon, Jan 23, 2012 at 4:46 AM, Yakov Galka <ybungalobill@gmail.com> wrote: [...]
Unfortunately it boils to the interface whence you can get a c_str() to a UTF-16 string only.
That's not correct.
It's correct. I state that path::c_str() returns UTF-16 on Windows. It's a fact. So the encoding isn't an implementation detail but a part of the interface. So you can do a conversion, but it has different semantics because....
If you have a path p, and the imbued codecvt if UTF-8, you can always get a UTF-8 narrow string by writing p.string<std::string>(), so you can always write p.string<std::string>().c_str() if you want a const char* to a UTF-8 encoded narrow string.
...it has a different life time. path::c_str() has the same lifetime as the path, so would have the utf8-path::c_str(). If your app mostly needs UTF-8 strings, use std::string and only
convert to a path when a path is actually needed.
If your app mostly needs paths, use boost::filesystem::path and only convert to std::string when a std::string or const char* is actually needed.
My app needs UTF-8 paths. Don't use the term 'path' as synonym for 'boost::filesystem::path'. There are other paths in the world (QDir, Poco::Path) and yours are neither special nor better. -- Yakov