|
Boost : |
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk