Jens Theisen wrote:
David Abrahams wrote:
It is a class templated on a value_type to with implementations can be attached (at run time). For example:
List< char > l = makeList(some_std_string) + makeList(some_char_array);
l.begin(), l.end() give you an iterator which type depends solely on the value_type (char in this case), rather than the iterator types used as backends (std::string::iterator and pointers). These iterators will iterate over the std::string first and after this over the char array.
AFAICS it is always possible to implement a resonable operator== as long as you apply the same restriction as for std::container iterators. I.e. comparing iterators from different sequences yields undefined behaviour.
I don't see why that would be incompatible with forward traversal. We don't even seem to have a requirement that a copy of an iterator compares equal with it. Perhaps we should; then you might be in trouble [Jeremy, Thomas, your thoughts?]
Oh, you're right. I somehow assumed that would be the case. However, this is a requirement for Forward iterators, and iterator_faced gives the forward_traversal_tag to Forward traversal iterators with reference reference type. So it maybe a good idea to add this requirement.
That shouldn't be slow if there's plenty of inlining.
The indirections are runtime indirections.
You can always have a fast path for comparison to the end iterator. Regards Thomas -- Thomas Witt witt@acm.org