Boost logo

Boost :

From: Bjørn Roald (bjorn_at_[hidden])
Date: 2008-05-29 17:04:04

John Femiani wrote:
> Also
> 'resource'
> 'resource_name'
> 'child'
> 'child_name'

Hm, regarding parent and child suggestions, considering a path may be
something like this:


what end is child and parent?

Rather than just complaining I throw in what I find natural. I have not
really considered how this would effect current users or other useful
conventions, so please ignore all that is useless. Otherwise I am glad
if it helps.

For me the path is something that describe a path *from* somewhere in
the graph/tree *to* somewhere which most often is somewhere else in the
same graph/tree. It describe a directional traversal between connected
nodes in the graph. If the *from* node are special well known places in
the graph we have special cases for the interpetation of the file
traversal, such as a for the file system root, web server document root
and so forth.

STL begin() and end() for iterators and front() and back() for access to
the elements at each end of the path come to my mind. However which is
front and which is back()? When i backtrack a path I, in my head, move
toward the front -- arghhh --- so maybe the simple and plain "from" and
"to" are best after all. Let us try:

path p1("a/b/c");
path p2("a/b/c/d.tar.gz")
p1.from_name() == "a"; // path is from directory called "a"
p1.to_name() == "c" // path goes to file or directory
called "c" == "d.tar.gz" == "c" // name of last node
p1.from() == path("a"); // path to first node in p
p1.from().name() == p.from_name() == ""
p1.to_name().ext() == ""
p1.name_ext() == "" == ".tar.gz"
p2.to_name().ext() == ".tar.gz" == ".tar.gz"
p2.name_ext() == ".tar.gz" == "c" == "d"
p2.name_base() == "d" == path("a/b/c") // path to last node in p; p == ??? == p.to_name()
p1.file() == path("a/b/c") // even though a may be a directory
???? in unix all is files :-)
p1.file_name() == "c" // only node in p that *may* be a
file, a good (but taken) alternative here is basename()
p1.file_name() == p1.file().name()
p1.file_path() == "a/b/c" // probably not very useful as p ==
p1.dir_name() == "b" // first directory backtracking path
from p:to()
p1.dir() == path("a/b") // shorten path by 1
p1.dir().dir() == path("a") // shorten path by 2
*p1.begin() == p1.from()
*--p1.end() ==
*(p1.end()-2) == p1.dir()
(p1.end()-2)->name() == "b";

This may only feel right if we think of the result of from() and to() as
absolute locations, i.e. something more like absolute paths. And that
may make sense here, I am not sure. However, if we think of it in
context of the path object it operates on rather than the file system
the path object may be associated with, it make sense to me.

Also, files may only be referred in the path::to() node, the
path::from() node and all intermediate nodes in the path traversal must
be directories. Symbolic links are just an edge to, or alias to, a
directory if it is internal in a valid path. So path::file() may
logically be the same as path::to() even if it is not connected to a
filesystem with absolute location of the p.from() node defined. Hence,
checking on validity of path in general and if last node is a file is
not feasible. Operations on a filesystem using a path object may return
an invalid value if there is a directory at path::to() location in the
filesystem, but that is after the path is put in specific context.


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