From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-07-19 19:40:27
At 07:39 AM 7/18/2002, Thomas Witt wrote:
>On Monday 15 July 2002 18:30, Beman Dawes wrote:
>> The Filesystem Library has been updated in the Boost sandbox CVS.
>
>I just had a look aat the docs. Something that seems to be error prone
>to me is that bool empty(path const&) and bool path::empty() have
>different semantics.
>
>I barely manage to keep in mind whether release is a member or not for
the
>smart pointer of the day.
Good point.
The underlying problem is that a path is conceptually a container. A very
limited one, to be sure, but none the less a path conceptually contains a
sequence of str::strings representing the names of the directories and file
(if any). I always think of a path as containing a
std::vector<std::string>, but any sequence will do. Implementations may
really maintain the internal state as a string, but conceptually it is
still a sequence of strings.
This conceptual model of a path, not tied to any particular format for
representation as a single string, is what ensures portability even in the
face of extreme operating system idioscynrocies.
Mostly users aren't overly concerned with getting at the path contents as a
sequence of strings, except may the last one (see path::leaf()). But there
will be applications that want to iterate over the strings. You can't just
say "well, parse the generic_path() output string into sub-strings" because
there may be no unambiguous parse. That's a fact of life for operating
systems that allow slashes in directory or file names.
(There is the possibility of providing an escape for slashes; that would
make the potential ambiguity to a bit less likely.)
That's a long way of saying that class path really needs some standard
library container-like functions, or maybe a way to export a
container. The path::empty() function came about because I got tired of
writing (for path foo):
if ( foo.generic_path().empty() ) ...
And wanted to write instead:
if ( foo.empty() ) ...
The name "empty" came from the same function in standard library
containers.
Anyhow, it may be easier to know what to do about path::empty() once the
question of how to provide a container-like (rather that the current
string-like) views of the contents of a path.
--Beman