Boost logo

Boost :

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 (

Boost list run by bdawes at, gregod at, cpdaniel at, john at