Boost's iterator.hpp is deprecated, too. Therefore get rid of all of that and replace inheritance by lifting std::iterator's members into the derived class.
Signed-off-by: Daniela Engert <dani@ngrt.de>
Regardless of value categories of a transform_iterator object, its
dereference operator calls m_f as an lvalue. Thus, correct usage of
decltype-based result_of is result_of<const UnaryFunc&(...)>.
Both make_function_input_iterator(function) and make...(&function)
do not depend on function_reference_input_iterator. Actually, passing a
function reference as a template argument to function_input_iterator is
not supported. Doing so results in compiler errors.
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>
