Boost logo

Boost :

Subject: Re: [boost] Is there interest in portable integer overflow detection, with policy based handling?
From: Ben Robinson (cppmaven_at_[hidden])
Date: 2012-02-23 23:42:36

On Thu, Feb 23, 2012 at 5:59 AM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:I would expect the result type of dividing
unsigned verified_int and signed verified_int to be signed verified_int.
Couldn't this help to avoid the overflow on operator/()?

> Of course, if the user assigns a signed to an unsigned, overflow must be
> checked.
> I would also prefer that there is no implicit conversion from signed to
> unsigned verified_int. A specific cast could be used for this purpose.
> unary minus operator on unsigned verified_int could also result on a
> signed verified_int.
> I agree with you on preventing implicit conversions. As far as the return
types of math operations, the resulting type is always that of the LHS.
The leftmost type in a sequence of binary math operations is used for the
entire computation, as it is processed left to right.

My philosophy on verified_int, is that overflow should be detected, not
avoided. If the author needs a larger data type, then this library will
catch that overflow, and the data types can be increased to accomodate the
necessary ranges. I do mostly embedded development, and many data types
are chosen to minimize space. This library was designed to add overflow
detection only, and not implicitly convert data types. That way, once
overflow was proven to not exist in a code base, the verified_int could be
replaced with the underlying types via some typedefs, and the run-time cost
is completely eliminated. If verified_int starts doing more than just
checking, than changing to the underlying types would change the system's
behavior, an undersirable effect. We agree on this point I believe.

Thank you,

Ben Robinson

> Just my 2 cts,
> Vicente
> ______________________________**_________________
> Unsubscribe & other changes:**
> mailman/listinfo.cgi/boost<>

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