The descriptions for portable_name() and portable_directory_name() appear to be at odds. portable_name() : ... && (name is "." or "..", and the first character not a period or hyphen) portable_directory_name(): ... && (name is "." or ".." or contains no periods) Should portable_name() be "... && (name is "." or "..", or contains no periods) && (first character not a hyphen)"? Maybe I'm missing something?
Scott McMurray - treat as Wish List:
- 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.]
© Copyright Beman Dawes, 2010
Distributed under the Boost Software License, Version 1.0. See www.boost.org/LICENSE_1_0.txt