Subject: Re: [boost] [filesystem] Version 3 of Boost.Filesystem added to trunk
From: Alexander Lamaison (awl03_at_[hidden])
Date: 2010-06-03 20:32:54
On Thu, 3 Jun 2010 20:04:26 -0400, Beman Dawes wrote:
> On Thu, Jun 3, 2010 at 6:48 PM, Alexander Lamaison <awl03_at_[hidden]> wrote:
>> On Wed, 2 Jun 2010 11:07:34 -0400, Beman Dawes wrote:
>>> * Any other comments or suggestions?
>> Some code I have wraps a SFTP library that returns paths as UTF-8 strings.
>> These need to be converted to the local code page before displaying to the
>> user. My original plan was to typedef basic_path with a traits class of my
>> own that I could imbue with a specific locale to do the conversion.
>> With FSv3 the only way to do this seems to be path::imbue() which imbue
>> *all* paths, globally. Or am I missing something?
> Yep, there is another way. First convert the UTF-8 string to a UTF-16
> string using software of your choice. Then construct a
> boost::filesystem::path with the UTF-16 string as an argument.
> Alternately, assign the UTF-16 string to a boost::filesystem::path.
> Say the resulting path is named p. Then p.string() will return a
> std::string containing the path in native format, native codepage.
> Does that solve your problem?
Possibly, I'll get back to you once I've actually tried implementing
My next questions related to the Windows API A/W variants. Another library
I've written many generic functions that wrap these kinds of API calls by
taking a basic_path and selecting the A or W variant depending on whether
the caller passes a basic_string<char> or a basic_string<wchar_t>. I
imagine this is going to be hard to port to v3 if I still want the caller
to be able to select the A or W variant.
Is there any reason why I should even care about being able to call the A
variants? My original theory was that someone could write a program that
always used basic_string<char> and could use that on Win9x but I've not
actually tested that theory.
-- SFTP for Windows Explorer (http://www.swish-sftp.org)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk