RE: [boost] input_iterator_facade (was: Re: [iterator facade] Why is dereference const?)
I still don't understand which design, yours or mine, is better. It seems mine allows to create iterators with smaller number of lines, but maybe there's
something else.
Why do you think so? I would say vice versa, since I do not require constructor in derived class to call found_eof(). Gennadiy.
Rozental, Gennadiy wrote:
I still don't understand which design, yours or mine, is better. It seems
mine
allows to create iterators with smaller number of lines, but maybe there's
something else.
Why do you think so? I would say vice versa, since I do not require constructor in derived class to call found_eof().
My line_iterator declares two constructors and 'get'. Yours defines, for stream_line_iterator_impl: one constructor, 'initialize', 'get', 'dereference' and 'equal' plus one constructor in basic_istream_line_iterator This is 1 class and 3 member functions vs. 2 classes and 6 member functions. - Volodya
I still don't understand which design, yours or mine, is better. It seems mine allows to create iterators with smaller number of lines, but maybe
Rozental, Gennadiy wrote: there's
something else.
Why do you think so? I would say vice versa, since I do not require constructor in derived class to call found_eof().
My line_iterator declares two constructors and 'get'. Yours defines, for stream_line_iterator_impl: one constructor, 'initialize', 'get', 'dereference' and 'equal' plus one constructor in basic_istream_line_iterator This is 1 class and 3 member functions vs. 2 classes and 6 member functions.
I do not put value directly into input_iterator_facade since it too much an assumption. So I need to method dereference in Policy. In your implementation input iterators almost never equal. Even though it is true in many cases. I still believe you couldn't assume it is always the case. So I need method equal in Policy. Actually my implementation was written couple years ago for classic iostreams. I forgot about getline version you are using when ported for Boost.Test needs. Once I switch to standard getline, I don't actually need method initialize anymore for my usage cases. I still not sure is it required in general. BTW don't you missed to call get() in line_iterator constructor? The question remains does we need all that flexibility. I believe - yes. Gennadiy.
Gennadiy Rozental wrote:
My line_iterator declares two constructors and 'get'. Yours defines, for stream_line_iterator_impl: one constructor, 'initialize', 'get', 'dereference' and 'equal' plus one constructor in
basic_istream_line_iterator
This is 1 class and 3 member functions vs. 2 classes and 6 member
functions.
I do not put value directly into input_iterator_facade since it too much an assumption. So I need to method dereference in Policy. In your implementation input iterators almost never equal. Even though it is true in many cases. I still believe you couldn't assume it is always the case. So I need method equal in Policy.
Do you have a case for 'equal'? Since you can't use input iterators for multi-pass algorithm, I cannot imagine a case where comparing two non-past-the end iterators is desirable.
Actually my implementation was written couple years ago for classic iostreams. I forgot about getline version you are using when ported for Boost.Test needs. Once I switch to standard getline, I don't actually need method initialize anymore for my usage cases. I still not sure is it required in general. BTW don't you missed to call get() in line_iterator constructor?
Probably....
The question remains does we need all that flexibility. I believe - yes.
I guess we're back to your old disagreements about flexibility. Flexibility is fine, but it adds complexity, both for implementors and the user, so flexibility should be added only when absolutely necessary. The eof_iterator is intented to be as simple as possible. - Volodya
participants (2)
-
Gennadiy Rozental -
Rozental, Gennadiy
-
Vladimir Prus