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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-11-12 11:34:55

At 02:20 AM 11/12/2004, Vladimir Prus wrote:
 >Beman Dawes wrote:
 >
 >> The critical technical change required is internationalization. The 
plan
 >> is to provide a templated basic_path class, with typedefs for path and
 >> wpath. In other words, an approach very similar to the current
 >> std::basic_string, std::string, and std::wstring.
 >
 >I don't this that's a good idea. Which type is supposed to be used in
 >binary library interfaces? path or wpath?

For the operations functions, neither. Instead a common base class which 
works for any kind of basic_path. That way you don't expose the native API 
in headers, or get a size explosion.

 > If 'path', then what happens
 >if I pass a wpath to that library?

Implementation defined conversion occurs.

 > If 'wpath' should always be used,
 >then why would I ever want to use 'path'?

wpath would be a much better choice for programs which are expected to 
handle international character sets. path is fine for programs which never 
expect to handle international character sets.

 >I'd be much happier with design like this:
 >
 >class path {
 >public:
 > path(char*);
 > path(wchar_t*);
 > string file_string() const;
 > wstring file_wstring() const;
 >};

A single path class approach is really interesting. Note, however, that it 
is a good bit more complicated than your synopsis above because of the need 
to provide templated member functions to handle user defined types. Ditto 
for std:basic_string types. One of the advantages is that it extends to 
user programs some of the flexibility that otherwise would only be 
available by hand coding overloads of user function.

I spent awhile last week trying to work out the specifics of a single path 
class approach. Most of it worked pretty well. What stopped me was that if 
a user is allowed to supply conversion functions, then it is easy to 
inadvertently compose paths (via operator /=) which mix encoding schemes in 
the same path. The thought of a filename encoded as UTF-8 living in a 
directory encoded in shift-JIS boggled my mind. Is this something that we 
should allow the user to do, if they wish, and if their O/S gives them 
enough freedom to do so? Or is it so perverse we are negligent in making it 
easy?

I'll give the single path approach some more thought, going on the 
assumption that there is no need to detect or diagnose mixed encodings. 
That was the showstopper, but it is probably overly protective.

 >Could you comment on the discussion we had on this on the Boost-users 
list:
 >
 >   http://thread.gmane.org/gmane.comp.lib.boost.user/6337

It just takes too much time to comment in detail. Mostly I agree with you 
and Peter, but wonder if you are aware of some of the committee's views. 
Need to support various string types, proposal to add wide character 
filename signatures, etc.

Thanks,

--Beman