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: Nat Linden (nat_at_[hidden])
Date: 2012-11-02 13:30:16

On Fri, Nov 2, 2012 at 12:06 PM, Nathan Crookston
<nathan.crookston_at_[hidden]> wrote:

> Given that s references the last element, and r is the past-the-end
> iterator, then it would imply that your syllogism is true.

That's really the question, isn't it. If a container's end() method is
documented to return a bidirectional iterator, is that iterator value
guaranteed to be past-the-end, or might it reasonably be a singular
iterator?

> Of course, a previous section (24.2.1.5) talks about the possibility
> of singular iterators and default constructable iterators.  I've never
> seen such things in the context of a bidirectional iterator.

Good to know...

My question all along has been: to a knowledgeable reader, is the
documented assertion that boost::filesystem::path::const_iterator is a
bidirectional iterator sufficient to imply that, given a non-empty
boost::filesystem::path value, you can validly decrement and
dereference the iterator returned by path::end()?

It appears that there's room for doubt about this implication.

For me, the bottom line is a request to add to the Boost.Filesystem
documentation a promise that it's valid to traverse a
boost::filesystem::path value backwards by decrementing the value
returned by path::end().