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
At 06:50 PM 11/12/2004, Peter Dimov wrote: point
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 on 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... --Beman