Re: [boost] Wave C++ Review Begins Today - February 7, 2005

From: Doug Gregor (dgregor_at_[hidden])
Date: 2005-02-09 13:49:01

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