By using Boost.Iterator we rely on the separate traversal category instead of
the standard iterator category to advance iterators efficiently. For instance,
this allows to advance transform iterators over a random access sequence
in constant time, despite that they are formally input iterators.
Also, std::reverse_iterator formally requires at least bidirectional iterator
as the underlying iterator type. Transform iterators from the example above
don't qualify, so potentially std::reverse_iterator could fail to compile.
The new implementation tries to detect if the incremented/decremented type
is an iterator first and if not falls back to operator probing. This way
iterators that are not SFINAE-friendly (i.e. unconditionally define
arithmetic operators regardless of the iterator category) are still treated
as iterators through std::advance and do not fail the compilation.
The iterator detection is based on probing for the nested iterator_category
type that is expected to be present in class-type iterators. This heuristic
is not flawless since iterators are not required to defined this type.
User-defined iterators may not have it and instead specialize
std::iterator_traits. This use case is not covered by the current implementation
and will likely fail to compile. With C++17 SFINAE-friendly std::iterator_traits
this can be fixed, but currently Boost.Config lacks the macro to detect
availability of this feature. Support for it can be added by a later commit.
Also simplified boost::prior for iterators, removing the possibility of
integer overflow caused by negation of the distance value.
The new version should provide the expected behavior in the case (prior(v.end(), v.size()) == v.begin()). It should also work with integers now, as was originally intended by David Abrahams. Added tests to verify these new use cases.
A comment in boost/iterator.hpp and boost/detail/iterator.hpp mentions that
the files are obsolete and will be deprecated. All they do is pull some types
from namespace std into namespace boost.
Some (strict) C++03 compilers (e.g. `gcc -std=c++03`) reject
'reference-to-reference' in the template and typedef which described
in CWG DR106 [1].
In such situations, iterator_facade rejects reference type as a value
type and some special iterators will become ill-formed:
the test libs/range/test/join.hpp might be descriptive.
[1] http://www.open-std.org/Jtc1/sc22/wg21/docs/cwg_defects.html#106
Signed-off-by: Kohei Takahashi <flast@flast.jp>
Also added an import into the boost::detail namespace for backward compatibility with Boost.Range. Added a pure_iterator_traversal metafunction that automatically converts iterator category as well.
This change excludes boost:: and boost::detail:: namespaces from ADL for unqualified function calls (e.g. algorithms). This reduces the possibility of name clashes with other libraries and user's code. One of the effects should be fixing test failures on gcc 4.2 and 4.4 due to clashed with Boost.TypeTraits.
Also some of the functions marked with inline keyword.
This makes iterators defined using iterator_facade more friendly to type inspection and fixes its use with next()/prior() since commit 651a869d4f.
The arithmetic, indexing and relational operators are only defined if the iterator category or traversal permits that. Note that the implementation requires partial template specialization support now.
