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.
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.
- Fixed multiple broken links to the documentation. Converted some of the
links to internal references to the QuickBook documentation. Not all
links converted because some of the QuickBook pages are not completely
converted.
- Renamed utilities.qbk to type_traits.qbk and removed the part duplicated
by concept_checking.qbk.
- Renamed traits.qbk to iterator_traits.qbk to better disambiguate with
other type traits documented in type_traits.qbk.
- Converted some of the headings in iterator concepts to sections to be
able to give those sections ids. This allows to reference those sections
from other places in the documentation.
- In order to preserve the more compact pagination of the new sections
(i.e. to have multiple sections on one page, like it was with headings)
set chunk.section.depth=2 in the docs Jamfile.
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.
