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

Subject: Re: [Boost-users] [Filesystem] Reverse traversal of boost::filesystem::path::const_iterator?
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-11-02 18:39:34

On Wed, Oct 31, 2012 at 10:07 AM, Nat Linden <nat_at_[hidden]> wrote:

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

If an iterator is bidirectional, you can decrement any iterator not equal
to the begin of the range. I.e., decrementing from end is fine (so long as
the range is non-empty).

- Jeff