$include_dir="/home/hyper-archives/boost-users/include"; include("$include_dir/msg-header.inc") ?>
Subject: [Boost-users] [Filesystem] Reverse traversal of boost::filesystem::path::const_iterator?
From: Nat Linden (nat_at_[hidden])
Date: 2012-10-31 13:07:44
I've stumbled across some code in our code base that wants to walk up
a fixed number of containing parent directories from the starting
path. (It's in a Mac application bundle nested within another.)
boost::filesystem::path::[const_]iterator is described as
bidirectional. But boost::filesystem::path has no rbegin() or rend().
In libs/filesystem/test/path_test.cpp's iterator_tests(), I see, for a
path variable named itr_ck, use of boost::prior(itr_ck.end()). That
suggests that usage of this form would be legal:
path mypath = /* ...something... */;
for (path::const_iterator rcomp(mypath.end()), rend(mypath.begin());
rcomp != rend; --rcomp)
{
// ... use boost::prior(rcomp) ...
}
Am I correct? Given the way some containers implement end(), I always
feel nervous about decrementing end(). I'm happy to see that
Boost.Filesystem's own tests guarantee that usage; but is there
anything in the documentation that would have assured me of that?