[boost] Path access to underlying sequence [was: Filesystem library updated]

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