On Fri, Nov 2, 2012 at 12:06 PM, Nathan Crookston
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().