STL Iterator Debugging and Secure SCL

For one thing, the C++ standard actually specifies that a vector reallocation invalidates all iterators and pointers. If VC would do otherwise, it would break the standard (this is probably because when the standard was written a lot of implementations were already around, and a lot of those used plain pointers for the vector iterators, as the video says).

Also, if this was implemented it would likely have a similar cost to what iterator debugging has. Only, now you can't turn it off for your release builds because it would change the semantics of your program. It would simply be too slow.

#define _CRT_SECURE_NO_WARNINGS
#define _SCL_SECURE_NO_WARNINGS

#ifndef _DEBUG
#define _SECURE_SCL 0
#endif

#define NOMINMAX

[littleguru]
> I wonder why the iterator is not following to the new location, when the resizing of a vector happens.
> Is that to slow or why isn't that implemented?

It would be way too expensive (both space and time). C++ is supposed to be blazingly fast, so the Standard avoids mandating anything that could be expensive. Especially when it doesn't buy anything fundamentally useful.

It would actually be more expensive than _SECURE_SCL, which is already unloved.

You can always use indices, which aren't invalidated by reallocation.

> And why is it a linked list that keeps track of the iterators and not a "vector"-like (dynamic array) construct?

_HAS_ITERATOR_DEBUGGING's singly-linked list is actually formed from the iterators themselves, which avoids performing any dynamic memory allocations. The iterators of Standard containers aren't allowed to have throwing copy ctors (23.1/10), which is exactly what dynamic memory allocations would do.

[Sven Groot]
> For one thing, the C++ standard actually specifies that a vector reallocation invalidates all iterators and pointers.

Note that the Standard's idea of invalidation is a theoretical concept. Iterators, pointers, and references can be theoretically invalidated (e.g. by vector reallocation) without being physically invalidated. For example, if we attempted and succeeded at in-place reallocation, then we wouldn't physically invalidate anything, but the Standard would still say that things have been theoretically invalidated.

> If VC would do otherwise, it would break the standard

If the Standard says that X theoretically invalidates Y, then it's conformant to make X not physically invalidate Y.

[PhrostByte]
> Raises hand as one of those C++ developers that always disables secure scl.

You have to be careful when doing this, as I mentioned in the video, if you use something like Boost.

Stephan T. Lavavej, Visual C++ Libraries Developer

We'll certainly avoid physical invalidation whenever there are performance advantages in doing so (e.g. in-place reallocation, which I'm looking at for VC10).

_HAS_ITERATOR_DEBUGGING will always complain about theoretical invalidation, and it is extremely strict.  For example, if you insert-at-middle without triggering reallocation, you've theoretically invalidated all iterators beyond the inserted element.  Erasing that element doesn't make those iterators theoretically valid again, but they'll be physically valid.