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