From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-08-21 10:20:59
At 03:35 AM 8/19/2003, Yitzhak Sapir wrote:
> ... numerous use cases ...
>My feeling from all these examples is that a path string is inherently
>specific to the system for which it was specified, and can't really be
>ported to anywhere else. Much like a string is usually inherently
>in its encoding to the system-specified encoding. However, the
>library can provide a portable way to manipulate this system specific
>much like the string library provides a portable way to manipulate the
>system-specific encoded string. In view of this, why try for a "portable
>path" at all?
There are plenty of use cases where no name portability checking is
required. Some require checking for the generic grammar, but do not require
checking for portable names. There are two variations on not checking for
portable names; (1) doing no checking at all (in class path, which amounts
to deferring the checking to the operations function calls where the O/S
API will do the checking), and (2) doing native checking.
All of you examples fall into those categories.
Then there are a number of use cases which do require some degree of name
The plan for the filesystem library is to support all of the use cases,
including the ones you identify. The most serious remaining questions have
to do with defaults. But regardless of how those defaults turn out, all of
the use cases will be supported one way or another.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk