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
>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.
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk