On Thu, Feb 18, 2010 at 11:43 PM, Scott McMurray <me22.ca+boost@gmail.com> wrote:

On 18 February 2010 09:43, Beman Dawes <bdawes@acm.org> wrote:

...

The first beta release of Boost.Filesystem Version 3 is now available.

Great!  I've been looking forward to it.

A few comments:

- read_symlink

Thank you!

Like a lot of features, it came about because someone asked for it.

- path::preferred

The implications of this one are strange to me.  I would have expected the path itself to always be stored in the portable grammar,

It is more efficient to store the pathname in the native format. A pathname is created only once, but it may be used many times. There may be some system specific aspects of the naive format that can't be represented in the generic format.

with the user-oriented display only done as a display issue, by using path::native.

- path::absolute

I agree that a verb here is important, since it's a mutator.  I don't have anything cleverer than make_absolute, though.

make_absolute() seems clearer than absolute(), so I'll go with that unless someone comes up with something even better.

 It's a shame that make_relative can't be done portably for anything beyond different root_names.

Yep. I tried briefly to come up with a make_relative spec, but didn't have any brainstorms. I'd like to be sure that there are reasonably compelling real world use cases before adding yet another function.

- canonical(p)

I'd like a non-member function specified to take an absolute path, expand any symlinks, and collapse any ".." path elements.

Whether it should allow a context to work with relative paths I'm unsure.

Essentially a "tell me what this path resolves to" function? I've occasionally though about such a function, but it always ended up be lower priority than other work.

- regarding complete

It seems like it'd just be canonical(path(a).absolute(b)), so it might not be needed.

I was also thinking that the need may have evaporated as other functionality was added.

 I suppose in some ways it's the version of canonical that takes a context.

Yes.

- uncomplete(p, base)

My pet request.  It may be useful to simplify other functions as well, since there's no current way to go from an absolute path to a relative one, meaning that most functions need to handle relative ones even when that might not be natural.  With this functionality, preconditions requiring absolute paths would be less onerous.

   Precondition: p.is_absolute() && base.is_absolute()

   Effects: Extracts a path, rp, from p relative to base such that canonical(p) == complete(rp, base).  Any ".." path elements in rp form a prefix.

   Returns: The extracted path.

   Postconditions: For the returned path, rp, rp.is_relative() == (p.root_name() == b.root_name()).

[Notes: This function simplifies paths by omitting context.  It is particularly useful for serializing paths such that it can be usefully moved between hosts where the context may be different, such as inside source control trees.  It can also be helpful for display to users, such as in shells where paths are often shown relative to $HOME.

In the presence of symlinks, the result of this function may differ between implementations, as some may expand symlinks that others may not.  The simplest implementation uses canonical to expand both p and base, then removes the common prefix and prepends the requisite ".." elements.  Smarter implementations will avoid expanding symlinks unnecessarily.  No implementation is expected to discover new symlinks to return paths with fewer elements.]

Interesting. I'm considering this a "Wish list feature request", so don't plan to do anything about it for the initial V3 release. Right now, all my effort is focused on issues that need to be fixed before the initial V3 release. Once that is in a good enough state to go into trunk (and release branch once tests are stable), I'll think about feature requests. Thanks, --Beman