Re: [boost] Is there interest in portable integer overflow detection, with policy based handling?

Subject: Re: [boost] Is there interest in portable integer overflow detection, with policy based handling?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-02-23 04:35:45

Le 22/02/12 16:56, Ben Robinson a écrit :
> It would appear there is interest in this library.  Therefore, I am making
> the full source available on GitHub here:
>
> https://github.com/cppmaven/VerifiedInt
>
> The library consists of three header files:
>
> verified_int.hpp (the integer class)
> verified_int_policies.hpp (the overflow handling policies)
> detail/verified_int_overflow_detection.hpp (the TMP overflow detection
> routines)
>
> In addition, you will notice that some of the hundreds of unit tests make
> use of the metaassert.hpp capability.  The VerifiedInt library contains a
> number of static assertions.  MetaAssert allows me to write unit tests,
> which will pass only if the static assertion fails instead of passing.  The
> trick is to convert what would be a compiler error into a runtime
> exception, and then detect the exception in the unit test.
>
Hi,

I've found this use of METAASSERT that trouble my understanding

// Prevent implicit conversion from one verified type to another
// on assignment via operator T() on the right-hand-side.
template <class R>
verified_int(R const prevented) {
BOOST_METAASSERT_MSG(sizeof(R) == 0, 
CANNOT_CONSTRUCT_FROM_A_DIFFERENTLY_TYPED_VERIFIED_INT, (R));
}

This doesn't prevent the implicit conversion, but makes it fail. This 
mean that if I have a function f overloaded with verified_int<X> and 
type ConvertibleFromR

void f(verified_int<X>);
void f(ConvertibleFromR);

the call

R r;
f(r);

will result on ambiguous resolution.

I guess that as verifier_int is templated with a policy, the detection 
mechanism should be public, and so it should appear in a public file and 
not inside the detail directory.

I don't know if the rational to have on each overflow policy almost all 
the operation logic is due to performance constraints.
Have you considered an overflow policy that contains only the action to 
do when there is an overflow?

Best,
Vicente