[Boost-users] [Filesystem] Reverse traversal of boost::filesystem::path::const_iterator?

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?