On Mon, Jul 19, 2004 at 11:50:57AM +0200, Stefan Slapeta wrote:
Stefan Slapeta wrote:
David Abrahams wrote:
If STLPort is complaining about that, it's because what you're doing is illegal. A default constructed standard container iterator is "singular", and no operations on it (including comparison) are legal other than assigning a non-singular iterator value into it. Although a few specialized iterators in std:: work differently (e.g. istream_iterator), in general you have to make the same assumption for any other iterator.
Very strange: the behaviour that the default constructor equals the past-the-end value is used for the example but it's not even documented for the find iterator!
See the example: http://tinyurl.com/4vzlm
typedef find_iterator<string::iterator> string_find_iterator; for(string_find_iterator It= make_find_iterator(str1, first_finder("abc", is_iequal())); It!=string_find_iterator(); ++It) ...
See the find iterator documentation: http://tinyurl.com/53j5x
find_iterator(); Default constructor.
Construct null iterator. All null iterators are equal.
Postconditions: eof()==true <<
The example above implies that a find iterator which points to the last element will become a 'null iterator' after incrementation. (However, I didn't find this statement anywhere in the documentation)
Thus, fixing this bug would not only mean to provide a second function like 'make_find_iterator_end(collection)' that returns a proper end iterator but also to change the behaviour of iterators for incrementation to the past-the-end value etc.!
I would really like to hear what Pavol says about that...
As I said in the other post, you are right. There is no need for an extra make_find_iterator_end(...) functions. Current logic is correct, unfortunately, there was a bug in the equal function that caused the problems. Singular iterators should realy not be compared. In addtions, I owe to explicitly say in the documentation, that null iterator acts as the end-of-iteration tag. Best regards, Pavol