Problem with iterator adaptor lib and concepts

From: kevin_vanhorn_at_[hidden]
Date: 2001-06-07 16:52:26

I think we need replacements for the ForwardIterator,
BidirectionalIterator, and RandomAccessIterator concepts from the
standard library, as these require too much.  The problem is that they
require operator*() to return a reference, but for non-mutating
iterators you often want operator*() to simply return value_type.
This issue comes up in designing a matrix class, where you would
like to have row iterators, but you don't want to have to store an
array of objects just to be the referents to which the row iterators
point -- you want *rowit to give you a value that you can then use to
iterate over the elements of the row.

A proper redesign would orthogonalize things by separating out the
notion storage location from the notion of iteration.  We would have
iterator concepts specifying the manner of iteration (OnePass,
Forward, Bidirectional, RandomAccess) and separate concepts specifying
whether we were iterating over values or memory locations (e.g.,
additional ReferenceIterator and MutableIterator concepts.)

Anyway, this problem spills over into the Boost iterator adaptor
library.  I can't use the iterator_adaptor class template to define a
row iterator for my matrix class because the iterator_adaptor template
insists on adhering to the standard's overly-strict definition of a
RandomAccessIterator.  

I think the Boost libraries should get this issue right even if the
Standard doesn't (maybe doing so would help fix the Standard in the
future.)  What do the rest of you think?

P.S. It seems to me that there are similar problems with the standard
container concepts; they also are too restrictively defined, bundling
up too many separate issues together instead of factoring things into
orthogonal concept groups.