From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-04-10 12:15:59


>> The random access tag is in my opinion a strongest point of the
>> iterator, you can get a performance boost in many applications
>> (specially when implementing containers). I'm out of ideas about how
>> to solve this. Can't we live breaking the law? Should we create new
>> categories? Just let it as a "poor" input iterator?
>
> We already have new categories. It can report that it has random
> access traversal. It's just not allowed to have
> random_access_iterator_tag. See the "new iterator categories"
> document.

Sorry, I really wanted to say "random access traversal" instead of
random access iterator. Taking a snippet of the proposed implementation:

template <class T, class Difference = std::ptrdiff_t>
class range_from_ref_iterator
     : public boost::iterator_facade
           < range_from_ref_iterator<T, Difference>
           , T
           , boost::random_access_traversal_tag
           , T &
           , Difference>

Correct me if I'm wrong but what I want is to simulate a source of N
identical objects without modifying them, so I think this is a Readable
Iterator and a Random Access Traversal Iterator.

I would now propose something like:

template <class T, class Difference = std::ptrdiff_t>
class repeat_read_iterator
     : public boost::iterator_facade
           < repeat_read_iterator<T, Difference>
           , const T
           , boost::random_access_traversal_tag
           , const T &
           , Difference>

so dereferencing "repeat_read_iterator<T>" would return const T & with
random_access_traversal capability to be able move fast inside that
"virtual read-only array". Am I missing something? Do you see this read
only repeated sequence simulation useful to include it the iterator library?

Regards,

Ion