boost filesystem path as utf-8 revisited

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

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

On Fri, Nov 9, 2012 at 4:15 PM, Rush Manbert <rush@manbert.com> wrote:
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. [...] so that's what we're going to do. Unless someone (Beman?) tells me that it's not a good idea. ;-)
It is really simple to do this in compile time. The relevant lines to be changed are in windows_file_codecvt.cpp. Replace: UINT codepage = AreFileApisANSI() ? CP_ACP : CP_OEMCP; with UINT codepage = CP_UTF8; (twice). I was proposing doing this as a compile time configuration flag a long time ago. Unfortunately Beman mostly ignored me. Maybe you will have more luck. P.S. Hell, I do not understand why once a library is accepted into boost the author can just do whatever he gets onto his mind. Cheers, -- Yakov

On Nov 14, 2012, at 2:18 PM, Yakov Galka <ybungalobill@gmail.com> wrote:
I do not understand why once a library is accepted into boost the author can just do whatever he gets onto his mind.
Within the general scope of the library, the Boost library author owns the accepted library, as a reward for the effort required to get it accepted, if you like. If the library will undergo significant change, the author is expected to discuss it with the community, possibly even arranging for a mini-review. Only when the author becomes unresponsive for a significant time do we consider assigning a new maintainer. This is how Boost works. Community driven projects are like anything else designed by committee: they tend to be disjointed, overreaching, confusing, etc. However, Boost is a community. If you disagree with how things are done, suggest alternatives and discuss them on the list. You may alter opinions and be able to institute your ideas. ___ Rob
participants (3)
-
Rob Stewart
-
Rush Manbert
-
Yakov Galka