On Wed, Sep 19, 2012 at 08:42:12PM -0700, JonathonS wrote:
Thanks Nate for the link. It does look promising, but I am using Boost 1.47.0 and I can't upgrade unfortunately. It looks like Locale was introduced in Boost 1.49.0.
Is there a way to tell boost filesystem to not use locales and to treat all paths as UTF-8? Solaris paths are native UTF-8 and my customers will always pass in UTF-8 paths so there is no reason for them to be translated.
You could probably stub up a no-op codecvt and pass that in wherever Boost.Filesystem has an default codecvt parameter. It is only actually _used_ when you use the non-native string type, if you only ever use narrow strings, the actual codecvt functionality will never be called. As I understand it, your explosions is due to the codecvt() instantiation itself, not the actual use of it. As a closing note, don't top-post, try to trim out unnecessary context and reply in-line.
On Wed, Sep 19, 2012 at 1:58 PM, Nathan Crookston
wrote: Hi,
On Wed, Sep 19, 2012 at 1:44 PM, JonathonS
wrote: Hi,
I am currently battling a buggy locale implementation (or lack thereof) in GCC on Solaris, which is affecting my use of boost::filesystem.
Please have a look at the following thread for more information regarding this: http://gcc.gnu.org/ml/gcc-help/2009-09/msg00212.html
In short, Solaris/GCC has a huge limitation that it does not support locales besides "C" or "POSIX". I talked to the GCC folks regarding this issue, and they said that at ONE time, GCC implemented the locale support for Solaris, but over time, the code was not maintained and therefore died :(
So, my question is whether anyone knows of a work-around for this?
I haven't tried it, but would using boost::locale in conjunction with filesystem work? Perhaps imbuing an ICU-backed locale would help, as shown in: http://www.boost.org/doc/libs/1_50_0/libs/locale/doc/html/default_encoding_u...
-- Lars Viklund | zao@acc.umu.se