Re: [boost] Re: Re: [iterator facade] Why is dereference const?

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-05-17 01:07:36

Gennadiy Rozental wrote:
> >     http://zigzag.cs.msu.su:7813/iterators/eof_iterator.hpp
>
> Interesting. I have very similar design that I call input_iterator facade.
> The only difference is that I do not have found_eof() interface. Instead I
> use result value of get method. So increment looks like:
>
> void increment()
> {
>     m_valid = static_cast<Derived&>(*this).get();
> }

Interesting... and I presume 'equal' works by comparing 'm_valid'? 

> Unfortunately new design does not allow you to call get in constructor. 

Why? Because constructor of your input_iterator_facace is run before 
constructor of derived class? But maybe resposibility of calling 'get' should 
be on derived class, at least that's how my eof_iterator works.

> I 
> even thought to present version that uses mixed old/new design with
> input_iterator_facde accepting policy that implements get method.

I'm not yet sure what are advantanges/disadvantages. 

I see some other way for improvement: maybe in some cases storing 
"m_at_eof"/"m_valid" flag is not necessary and derived iterator can provide 
method "at_eof". That would save some space.

>  Anyway why don't we add something like this in iterator library. I found
> it quite usefull (tokeen_iterator could use it for example)

I wonder what iterator library authors think about it? Since eof_iterator is 
used by the program_options library it need to exist in CVS somewhere... is 
it OK to put in in "boost/iterator" as opposed to "boost/program_options"?

- Volodya