Boost logo

Boost :

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
>> 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 {
> 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

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

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.



Boost list run by bdawes at, gregod at, cpdaniel at, john at