RE: [Boost-users] Re: Re: Feature request for boost::filesystem

From: Delfin Rojas (drojas_at_[hidden])
Date: 2004-07-06 12:49:01

I think you bring very good points. When you receive a path object back from
a directory iteration and you want to convert it to string it is really
dangerous to expose both narrow and wide strings because the caller doesn't
know if the string had a good conversion or not.

On the other hand, I don't agree these arguments say the narrow vs wide
decision cannot be made at compile time. If the programmer compiles the
library for single character strings then she/he knows what to expect. After
all a project in Windows gets compiled for single char or double char
strings. 

Boost::filesystem can talk to several filesystems from within a single
program but it currently has only two implementations; one implementation
for POSIX and one for Windows. On Windows OS all the calls to any file
system will happen through the Windows API which takes narrow and wide
strings. In the POSIX system there is no wide string support for the file
system so the library should work with narrow strings internally.

-delfin

-----Original Message-----
From: boost-users-bounces_at_[hidden]
[mailto:boost-users-bounces_at_[hidden]] On Behalf Of Peter Dimov
Sent: Tuesday, July 06, 2004 3:35 AM
To: boost-users_at_[hidden]
Subject: Re: [Boost-users] Re: Re: Feature request for boost::filesystem

Eddie Diener wrote:
> Vladimir Prus wrote:
>>
>> With a bit of additional design, it's possible to make library use
>> one representation internally, and have either non-templated
>> interface, or a tiny templated facade. E.g:
>>
>>    boost::path p;
>>    p = p / L"foo" / "bar";
>>
>> does not seem all that bad thing for me.
>
> It is possible to do that if you can convert all character types into
> your internal representation. Even here I am paying for conversionsa
> back and forth I may not need. I therefore would prefer separate
> templated libraries.

I'm not sure which conversions back and forth you have in mind, and how
separate templated libraries avoid them.

The goal of Boost.Filesystem is to allow you to write OS-independent code.
However the native path character is OS-dependent. So if you, for example,
enumerate a directory, you will get back paths that are either narrow or
wide, depending on the native character type.

You cannot make the narrow vs wide decision at compile time (assuming that
the code does not change), because (1) there are wide paths that do not have
a narrow representation, and vice versa; (2) Boost.Filesystem can talk to
several different filesystems from within a single program.

It is possible to typedef basic_path<_Native_fs_char> path, but then

p /= "images";

may fail - you'll need to use BOOST_FS_PATH("images") or something equally
ugly.

_______________________________________________
Boost-users mailing list
Boost-users_at_[hidden]
http://lists.boost.org/mailman/listinfo.cgi/boost-users