Boost logo

Boost Users :

Subject: Re: [Boost-users] [Filesystem V3] Filesystem Version 3 beta 1 available for download and comment
From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2010-02-18 23:43:45


On 18 February 2010 09:43, Beman Dawes <bdawes_at_[hidden]> 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!

- 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, 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. It's a shame that
make_relative can't be done portably for anything beyond different
root_names.

- 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.

- regarding complete

It seems like it'd just be canonical(path(a).absolute(b)), so it might
not be needed. I suppose in some ways it's the version of canonical
that takes a context.

- 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.]

~ Scott


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net