$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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