Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2006-09-11 09:02:59


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

>>You might want to take a look at SafeInt:
>>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncod
>>e/html/secure01142004.asp
>>It takes a different approach, which IMO is more convenient in most
>>situations than the free functions, it defines a wrapper class
>>template which controls all the arithmetic operations of the
>>underlying type. The code is copyrighted and highly
>>platform-dependent, but I think that if Boost is going to have any
>>arithmetic operations checking mechanism, then it should rather look
>>like this.
>
> I agree that C++ lacks of safe integers types but I disagree that
> throwing an exception is a good idea: - Overflows tend to happen under
> rare circumstances and tests usually don't cover all of them (or even
> don't cover at all)

That's all typical of anything that's reported by exceptions.

> - It's hard to view an innocent i = i + j as an expression that may
> throw -

A basic lesson one must learn to write exception-safe code: "innocent"
code might throw.

> Throwing an exception from a place where
> it's not expected often breaks invariants

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.

> (in C++, broken invariants are often subtle and dangerous) - No way
> to grep overflow checks -

What does that mean?

> 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?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk