Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2006-09-11 16:09:35

"Alexander Nasonov" <alnsn_at_[hidden]> writes:

> David Abrahams wrote:
>>"Alexander Nasonov" <alnsn_at_[hidden]> writes:
>>> (in C++, broken invariants are often subtle and dangerous)
>>> - No way to grep overflow checks
>>What does that mean?
> The first statement means that, for example you can leave some member
> uninitialized then an exception is thrown unexpectedly.
> The second that it's harder to identify all places where overflow
> checks are made. Compare i = i + j and is_mathematically_correct(_1 =
> _1 + _2)(i, j). The latter can be searched with grep -rl
> is_mathematically_correct .

Ah, that's a very interesting interface! I like it.

>>> Unlike ignored return types, compilers don't print any warning on
>>> ignored throw clause
>>> - I can hardly imagine that I change some int
>>> members of popular classes in a hope that it would magically work
>>> when I resolve hundreds of compiler erros
>>What does that mean?
> Sentence 1.
> If your goal is to identify all places where error checking is
> ignored, you may try to increase warning level and see if there are
> any "return value is ignored" warnings. However, it's not the case for
> errors that are indicated by throwing an exception.

Yes, I got that part.

> Sentense 2.
> You wrote:
>> True. You can't simply plug in something that throws where
>> something nonthrowing existed previously. These are not drop-in
>> replacements for unsigned integral types. Signed integrals
>> exhibit undefined behavior on overflow (IIRC), so arguably they
>> can be drop-in replacements for those.
> I meant exactly this when I wrote about changing a type from int to
> something close to int yet different because it may throw.

Where do "hundreds of compiler errors" come into it?

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at