Boost logo

Boost :

From: scleary_at_[hidden]
Date: 2000-12-18 14:09:34

I finally got a minute to look at your iterator adaptors
(concerns/suggestions are at the end, in section "Notes"). I have one
"extension request": the Range Iterator you provide can, with a bit of work,
be changed to do the same with iterators:

namespace details {
template <class IntegerType, bool IsArithmetic>
struct counting_iterator_traits_base;
template <class IntegerType>
struct counting_iterator_traits_base<IntegerType, true> {
  typedef std::ptrdiff_t difference_type;
template <class Iterator>
struct counting_iterator_traits_base<IntegerType, false> {
  typedef typename std::iterator_traits<T>::difference_type difference_type;
} // namespace details
template <class IntegerOrIterator>
struct counting_iterator_traits {
  typedef typename details::counting_iterator_traits_base<IntegerOrIterator,
  typedef IntegerOrIterator value_type;
  typedef IntegerOrIterator reference; // [1] not too sure about this
  typedef value_type* pointer; // [2] not too sure about this, either
  typedef std::random_access_iterator_tag iterator_category; // [3] very
shaky here

Then, given:
  template <class IntegerOrIterator>
        counting_iterator_policies>::type counting_iter(const
IntegerOrIterator i)
  { return iterator_adaptor<IntegerOrIterator,
                           counting_iterator_policies >::type (i); } // [4]
One can say:
  // Will insert each dereferencible iterator of c1 into c2:
  std::copy( counting_iter(c1.begin()), counting_iter(c1.end()),
std::back_inserter(c2) );
  // Inserts the values [0, 13) into v:
  std::copy( counting_iter(0), counting_iter(13), std::back_inserter(v) );

Notes (all of these apply to the Transform Iterator adaptor, too):
[1] I'm not sure that we should typedef a non-reference type to be
"reference". The only input iterator supplied by the STL has that typedef
as a (const) reference type.
[2] I think the "pointer" type should be "const value_type *".
[3] This adaptor does not return a reference type when dereferenced; thus,
it should only claim to be an input iterator (it can still support [], +=,
etc., though) (flame-resistent hat on now...)
[4] I think providing "constructor functions" for as many adaptors as
possible would be useful.

Note that if others agree with me on [1], a separate value_reverse_iterator
would be necessary.

The Vote: Yes, even if all my suggestions above are ignored. Actually, the
review ended yesterday, didn't it? Well, I vote yes anyway. :)


P.S. Indirect Iterator is really a special case of Projection Iterator.
Should the code/docs reflect that anywhere?

Boost list run by bdawes at, gregod at, cpdaniel at, john at