Boost logo

Boost :

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

Gennadiy Rozental wrote:
> >
> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at