Re: [boost] [filesystem] Major changes before standardization

From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-11-12 16:16:32

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