Boost logo

Boost :

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-10-21 22:46:02

----- Original Message -----
From: <fernando_cacciola_at_[hidden]>
> ----- Original Message -----
> From: "Paul Mensonides" <pmenso57_at_[hidden]>

> > Just a quick query about what you guys think should be done in overflow
> > situations with high-precision arithmetic in the preprocessor library.
> > have three options:
> >
> > 1) return a known (and detectable) error state
> > 2) saturate at the greatest value
> > 3) cause a glorious preprocessor failure
> >
> I think that the only truly useful options are (3) or [1+2].
> That is, either (1) or (2)[or any variance of 2] alone are useless.
> Others have recall that C's integral types don't usually signal overflow
> most arquitectures.
> As a numerical programmer, I've always found this to be more a problem
> a gain.
> Sure, it is faster, -but not so any more- but when overflow actually
> happens,
> many applications just drain into disaster.

Thanks for the comments, but keep in mind that we're talking about
arithmetic at the preprocessor level. Which basically means nothing that
can be consider real numeric work. The speed differences that I'm talking
about are all different than hardware arithmetic of any kind.

It seems to me that I might as well go with a complete failure.

Paul Mensonides

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