Witz <witz@nildram.co.uk> writes:
Firstly, is it really necessary to have the predicate as part of the template specification for the filter_iterator? Surely it can be assumed that it will always be convertible to boost::function<bool (const value_type&)> ?
There is significant run-time overhead when using boost::function, including a virtual function call. You can, of course, manually specify boost::function<bool (const value_type &)> as a the function type. Even if the template parameters for filter_iterator were reversed, so that it would be possible to specify a default value for Predicate, setting it to a boost::function type would require that boost.function be a dependency of filter iterator, even if the default value is not used, and would encourage (inefficient) use of boost::function even when the actual function type is known.
Secondly, by allowing the return type of the function used by the transform_iterator to be a reference can we not use it to implement a more generic form of indirect_iterator?
If the life-time of the value to which the returned reference refers is longer than that of the reference itself, then you can use projection_iterator, which is also a random access iterator. transform_iterator is designed specifically for the case that the returned value is not stored somewhere else, and consequently is only an input iterator. (This distinction is of little importance, however, in the new iterator adaptors library, which David Abrahams has proposed for standardization.) -- Jeremy Maitin-Shepard