
On Nov 6, 2012, at 11:55 AM, Rush Manbert wrote:
In the original thread, I found this reply by Beman: -----------------
How exactly do I imbue UTF-8 codecvt in a path? I Googled around and couldn't find anything.
There are two approaches:
* If you always want all class path arguments and returned values with a value type of char to be treated as being UTF-8 encoded, and aren't worried about changing a potentially dangerous global, then do this:
#include <boost/filesystem/detail/utf8_codecvt_facet.hpp> ... std::locale global_loc = std::locale(); std::locale loc(global_loc, new boost::filesystem::detail::utf8_codecvt_facet); boost::filesystem::path::imbue(loc); -----------------
I do want what is described and would like to use this approach, but we use boost::filesystem all over the place and in our code we never do any sort of "global initialization", so I'm trying to figure out how to get the code snippet executed.
I can see two ways to approach this: 1) Add this code snippet to the boost::filesystem::path constructor. But is it too late then? 2) Define a class whose only purpose is to execute this code when it is constructed and arrange to have a static singleton instance of the class defined. In one of our libraries we need to be very careful about static class construction order, so this may be difficult.
I haven't dealt with this sort of issue in quite a while and I may be a little rusty. Any suggestions? Are there new goodies in C++ that might help me?
Thanks, Rush
For the record, what I had been hoping for was a suggestion of a way to do this setup at compile time, and I'm not doing the work so I don't have the sources to play with. But I suggested that my colleague should look at what the imbue call does and see if we could do the equivalent. He came back with this change: // PAL 11/8/2012 - Default to UTF-8 encoding for path names // std::locale path_locale(std::locale(), new windows_file_codecvt); std::locale path_locale(std::locale(), new boost::filesystem::detail::utf8_codecvt_facet); so that's what we're going to do. Unless someone (Beman?) tells me that it's not a good idea. ;-) - Rush