Boost logo

Boost :

Subject: Re: [boost] [iterators] how about an identity_iterator or generate_iterator?
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2008-12-12 08:18:04


On Fri, Dec 12, 2008 at 9:01 PM, Jeff Flinn
<TriumphSprint2000_at_[hidden]> wrote:
> Dean Michael Berris wrote:
>>
>> Hi,
>>
>> Has anybody found a need for an "identity_iterator"? Something that
>> you can initialize to a value and returns that value every time it's
>> referenced? It could model a random access iterator, and a default
>> constructed version will mark an "end" of the identity_iterator.
>>
[snip wrong definition]
>
>
> How about:
>
> template< typename T >
> class identity_iterator
> : public boost::iterator_facade< identity_iterator<T>, T
> , boost::forward_traversal_tag, const T&>
> {
> public:
> identity_iterator(const T& value, int index)
> : m_value(value), m_index(index) {}
>
> private: // virtual overrides
> friend class boost::iterator_core_access;
>
> void increment() { ++m_index; }
>
> const T& dereference() const { return m_value; }
> bool equal(literal_iterator<T> const& rhs) const
> {
> return m_index == rhs.m_index;
> }
>
> private:
> T m_value;
> int m_index;
> };
>
> The index allows use with algorithms where and end iterator is req'd.
>

Looks good to me. :)

>>
>> Or even a "generate_iterator" which takes a nullary function object of
>> signature "tuple<bool, T>()" where bool indicates whether it's at the
>> end? It can be modeled as an input iterator. Something like:
>>
[snip bad attempt at example]
>>
>> Or is there already something out there which allows these iterator
>> semantics?
>>
>
> See:
> http://www.boost.org/doc/libs/1_37_0/libs/iterator/doc/function_output_iterator.html
>

But that's an output iterator -- I'm looking for something that
behaves like an _input_ iterator.

Perhaps something like the above, but instead of returning a value
calls an encapsulated function?

Thanks for the quick response Jeff!

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk