Re: bit_iterator

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-06-12 06:35:18

"Jan Langer" <yg-boost-users_at_[hidden]> wrote in message
news:3D04FF72.21DF504C_at_langernetz.de...
> hello,
> i do use iterator adaptor to build a bit_iterator, which return single
> bits of the elements of an underlying iterator. the base_type of my
> iterator_adaptor is std::pair <BaseIterator, unsigned int> representing
> the iterator and the bit position.
> now my iterator does not work if i adapt istreambuf_iterator because
>   self operator++(int) { self tmp(*this); ++*this; return tmp; }
> of iterator_adaptor is not able to use the proxy returned by the postfix
> increment of the input iterator.

What do you mean by "is not able to use"?

And anyway, where do you see a proxy? iterator_adaptor's postfix increment
calls its prefix increment, which calls policies().increment(*this). Your
policies must be able to do the right thing with your base iterator.

Note also that istreambuf_iterator is a pure input iterator (there's no
lvalue lying around to which a reference can be formed), so your iterator
will need to internally store the value_type of the istreambuf_iterator each
time it's dereferenced or the value will disappear before you get a chance
to extract the bits.

>
> now i searched the archive and found in:
>     Subject: Re: [boost] (infinite) sequences using recurrence relations
>     From: Corwin Joy < cjoy_at_xxxx >
>     Date: Fri, 10 Aug 2001 01:21:28 -0500
>
> the following sentence:
> >In table 72, p. 511 of the standard you will notice something weird about
> >the postfix increment operator:
> >Namely, it is specified as (void)r++.
> >In other words, unlike all other standard iterator types, an input
iterator
> >is not required to return a copy of its old value!
>
> but this would mean that the expression *i++ is wrong in most cases.
> is there a trick to make iterator_adaptor also handle this case

I think the internally-stored copy of value_type can help you.