Boost logo

Boost :

Subject: Re: [boost] Is there interest in portable integer overflow detection, with policy based handling?
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2012-02-22 07:15:30


Ben Robinson wrote:
> On Tue, Feb 21, 2012 at 4:58 AM, Toon Knapen
> <toon.knapen_at_[hidden]> wrote:
>
> > Can you elaborate on how this affects performance for
> > integer arithmetic?
> >
> 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.

I haven't seen any code, so I can't see exactly what you're doing, nor have I spent any cycles thinking about the details that would apply in what you've described. However, I wrote a library that does range checked assignment, in a new-style cast form (checked_cast). It never requires more than two comparisons (against the target's maximum and minimum values), and there's no subtraction. I use TMP to determine signedness and relative size to determine which comparisons are needed. Obviously, types with the same signedness only require underflow or overflow detection when the target type is smaller than the source type. Thus, I'm concerned that your range tests are not as efficient as they could be. (Then again, what you've done might optimize better, for all I know. If so, be sure to document that in a Rationale section.)

_____
Rob Stewart robert.stewart_at_[hidden]
Software Engineer using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP http://www.sig.com

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.


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