Hi all. I was wondering why filter_iterator constructors allow default parameter values? More precisely, if the end iterator parameter is not given then the constructor silently uses a default generated iterator as its internal end iterator. This interface seems dangerous to me and has caused us one hard-to-track-down bug... because the filter_iterator silently used an incorrect end iterator and so sometimes managed to iterate passed the end of its container... causing of course all sorts of cute behaviour... :-) (access violations, random API call failures, gibberish values read through the iterator...) The failures themselves were also random enough to make tracking this baby down a real pain in the behind... :-) Now we are bigger & wiser, but I was still wandering what the rationale was for using this interface? Why not simply make the end iterator parameter be mandatory? That would make it explicitly clear to the novice user that he needs to specify the end iterator. If there actually is some reason for implementing filter_iterators this way, could someone add a warning or a rationale explanation regarding this in the official documentation? Hope this helps... Best regards, Jurko Gospodnetiæ