On Feb 9, 2005, at 12:29 PM, Michiel Salters wrote:
I really have to say Dinkumware did a fine job here, this would have been very hard to find without these checks.
FWIW, STLport and newer versions of GCC (Apple GCC 3.3, FSF GCC 3.4) have similar debugging modes. They've been invaluable in rooting out subtle bugs like those that stem from iterator invalidation.
Oops, I forgot to mention that CodeWarrior has a debug mode, too.
Yep, although I'm currently wondering if they're 100% right.
Most likely, yes. They tend to be written by library lawyers who directly translate from the standardese to the most picky, specific implementation that the standardese allows. The usual complaint about debug modes is that they're too strict... for instance, a bug report was filed against GCC's debug mode because it complains when a singular iterator is copy-constructed. The debug mode is right, even though I've never seen a singular iterator that couldn't safely be copied.
Is it legal to compare iterators from different containers? I can't find the appropriate wording so I'll just trust Dinkumware here.
No, it is not legal to compare iterators from different containers. Operations that require two iterators mandate that the iterators be part of the operation's "domain". Iterators from different containers can never be in the same domain.
My current problem is, somewhere deep down in cpp_macromap.hpp a simple innocent if (first != last) statement (line 433) triggers another assertion. These are iterator_facade's (which I don't grok) and end up comparing iterators to two distinct containers. Looking the other way on the callstack, I see some deeply suspect iterators (singular, destroyed, ?)
Yikes... I'll dig into it when I get a chance to write my Wave review. Doug