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