"Alexander Nasonov" <alnsn@yandex.ru> 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