Re: [boost] overflow_traits

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
www.boost-consulting.com