On 19 September 2015 at 10:12, Jonathan Wakely <jwakely....@gmail.com> wrote: > On 19 September 2015 at 08:31, François Dumont wrote: >> On 16/09/2015 22:29, Jonathan Wakely wrote: >>> No, because it is undefined to compare iterators that belong to >>> different containers, or to compare pointers that point to different >>> arrays. >>> >> >> (Written before Christopher reply:) >> >> At least program will compile only if iterator is coming from a vector >> of the same type. So behavior is undefined only if user pass an invalid >> iterator which is exactly what this check tries to detect, isn't it >> paradoxical ? If this undefined behavior results in the program abortion >> this is what should happen anyway. If it doesn't abort then the program >> will definitely not behaves as expected so this check doesn't make >> anything worst, no ? > > The problem is that undefined behaviour can "travel backwards in time". > > It's not as simple as saying that if the invalid check happens _then_ > undefined behaviour happens afterwards.
Just to be clear, I agree that it can't hurt a correct program (except for the small cost of doing the checks). My concern was that for an incorrect program (which is the entire purpose of adding the checks) the results could be unpredictable. It might abort, which is the desired behaviour, or it might do something else and keep executing, and in that case it could be harmful for debugging because users would look at the source and think "well my iterators must be in range, otherwise that assertion would have failed, so the bug must be elsewhere". However ... > However, Google seem to find these checks useful, and you and Chris > are in favour, so let's keep them.
