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-21 20:54:45


On Tue, Feb 21, 2012 at 4:58 AM, Toon Knapen <toon.knapen_at_[hidden]> wrote:

> On Tue, Feb 21, 2012 at 7:04 AM, Ben Robinson <cppmaven_at_[hidden]> wrote:
>
> > <snip>
> > Does this pique anyone's interest?
> >
> > Can you elaborate on how this affects performance for integer arithmetic
> ?
>
> There are two components to the library, overflow detection, and overflow
handling. Overflow handling is policy dependent, but overflow detection is
built-in to the library, and a key feature.

The overflow detection routines were meta-programmed with respect to the
data types involved in the operation, in order to maximize performance.
Template specializations are provided for each detection routines, which
eliminate unnecessary operations based on both the signededness, and the
ranges on both data types involved in the operation.

For example, detect_addition_overflow performs only a single subtract and a
single compare if both data types are unsigned. If both data types are
signed, it will perform a maximum of one subtract, and either two or three
compares.

Because the detection routines are built into the overloaded math
operators, and does not require one to rewrite existing code to make use of
the detection, a developer could use these routines in a debug build, and
then simply supply the ignore_overflow policy for a release build, which
will inline out to zero overhead. Or even typedef to the library data
types for debug, and typedef to PODs for release. The usage is exactly
that of PODs.

In short, performance was a key consideration in the design and
implementation.

Thank you,

Ben Robinson

> thanks,
> toon
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


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