At 02:26 PM 11/12/2004, Peter Dimov wrote:
Beman Dawes wrote:
(probably because their O/S just traffics in raw chars, yet they need a wide character encoding.) These users would be helped a great deal by custom conversions.
I still don't get it. I guess that we need code. Either way, it is the user doing the conversion. They aren't helped one bit.
Yes, either way the user has to supply the conversion code. But without direct support, the user must call that code manually (or more likely in a user written wrapper.) But if path directly supports user conversions, then the conversion functions are called automatically by path objects when needed, and that is a win for the user.
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.
There is nothing the library can do, and providing smoke and mirrors just to make it _seem_ that other paths are supported, when in reality they simply are not, is both a disservice and a needless complication. IMO.
I don't understand why you say they aren't supported. Is it because the user is supplying the conversion functions?
One case where a custom conversion is required is for a user defined string type. There isn't any default; the user has to supply the conversion.
The user needs to convert the user-defined string type to either path or wpath. This is not something that the filesystem library can, or should,
do
for him; a function can handle this conversion easily.
Yes, of course. The question is whether the user calls the function directly, or passes it to the library so that the library will call the function when needed.
This use case does not imply that there must exist a basic_path for every basic_string, because
such a basic_path is not a filesystem path. The filesystem simply does not take user-defined strings, never will, and no amount of traitification can change that.
The filesystem operational functions never see the user-defined strings. Conversion has already occurred. The operational functions are not templated and only deal with the native_path_string_type.
...
Either way, we need examples before we can move the discussion forward.
I'll post proof-of-concept level code, but it will be several weeks. --Beman