Subject: [boost] boost::filesystem::path frustration
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-01-24 20:56:58
I'm finding that boost::filesystem::path seems to be a strange mix of
different beasts, unlike any entity we have in the STL. For example,
when you construct it from a pair of iterators, they're expected to be
iterators over characters, but when you iterate over the path itself,
you are iterating over strings of some kind (**). Even though, once
constructed, this thing acts sort of like a container, it supports none
of the usual container mutators (e.g. push_back, pop_back, erase) or
even queries (e.g. size()), making it incompatible with generic
algorithms and adaptors.
In particular, this comes up because I'm trying to find the greatest
common prefix of two paths. I thought this would be easy; I'd just use
std::mismatch. But even once I've found the mismatch I don't see any
obvious way to chop off the non-matching parts of one of the paths. I
end up having to resort to some really ugly code (or I just haven't
figured out how to use this thing correctly).
Why should paths be so different from everything else? I think, if the
design is actually right, some rationale is sorely needed.
Also,
* (**) the docs don't say what the value_type of path::iterator is. A
string value? A range that becomes invalid when the path is
destroyed? Ah!?! How surprising; inspecting the code shows it
iterates over paths! A container whose element type is itself is very
unusual!
* the docs claim you can construct a path from a "A C-array. The value
type is required to be char, wchar_t, char16_t, or char32_t", but
doesn't say how that array will be interpreted. From the wording I
might have assumed it accepts a CharT(&)[N] and the length of the
input is taken as N, but inspecting the code shows it expects a CharT*
and interprets the source as null-terminated.
Thanks,
-- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost