Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-11-12 20:19:01

At 06:50 PM 11/12/2004, Peter Dimov wrote:

>Beman Dawes wrote:
>> At 02:26 PM 11/12/2004, Peter Dimov wrote:
>>> We have two OSes in use today. Windows, which takes either path or
>>> wpath, and POSIX et al, which takes only a path. If the user wants to
>>> use something that is neither a path or a wpath, he must convert it
>>> to one of those.
>> Yes. Or more exactly, to "native_path_string_type" which is an
>> implementation defined typedef, AFAWK, always to std:string or
>> std::wstring.
>I'm not sure that this is the right way to handle "dual" OSes, such as
>Windows NT. On Windows NT both string types are "native" from the API
>of view. The library should not attempt to convert the path supplied from

>the user! This may or may not produce the desired results. The OS must be

>trusted to do the necessary conversion (it knows whether the filesystem
>which the path resides stores narrow or wide names, and how to convert
>between them in this particular context).

It might be messy to make the single path class approach work if Windows is
viewed as a dual rather than wide O/S.

   path p;
   p /= "foo";
   if ( some_bool ) p /= L"kühl";

   if ( exists( p ) ) ... // use wide or narrow API depending on some_bool

I guess path objects could keep track of whether or not they had ever been
modified by an argument other than a char string, and use the Windows wide
API. Seems messy...


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