RE: [boost] casts, exceptions, and asserts

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-10-26 18:09:13

----- Original Message -----
From: Darin Adler <darin_at_[hidden]>
To: Boost <boost_at_[hidden]>
Sent: Friday, October 26, 2001 7:39 PM
Subject: Re: [boost] casts, exceptions, and asserts

> on 10/26/01 3:35 PM, Fernando Cacciola at fcacciola_at_[hidden] wrote:
>
> > Should we sketch a "defect management configurable framework"?  What
about
> > the debugging tools submitted by Brian Parker a few days ago? Can that
be
> > made to fit here?
>
> I suggest an extremely simple framework. My proposal for the entire
> configurable framework would be:
>
>     #ifndef BOOST_ASSERT
>     # include <cassert>
>     # define BOOST_ASSERT(x) assert(x)
>     #endif
>
> Perhaps you want to propose a more-complex framework.
>
Well, a more complex framework will be usefull, but it will also take time,
so in the meantime I would really like to see this BOOST_ASSERT() introduced
as soon as possible.
That seems to me like an easy and totally controlled boost inclusion.

>
> I think the really tricky bit is to figure out how to name the proposed
two
> different versions of numeric_cast. One is more like dynamic_cast, and the
> other more like static_cast, but numeric_dynamic_cast and
> numeric_checked_cast would be terrible names.
>
Yes, terrible names... :-)

> I also realized that it would be good to have a third kind of numeric
> conversion, for generic programming. That would be a conversion that
asserts
> that no precision is lost. The current conversion throws an exception if
the
> result is out of range, but having one that asserts if the result loses
> precision would be useful too, I think.
>
Yes. I considered this too, but leave it out because the implementation is
rather involved; and I didn't want to scare people out with too much
complexity

Besides, I know how to implement it only for x87 coprocessors.

I figured that, once the proposal is generally reviewed, we can start
considering more sophisticated issues.
Some of them are:

  Detection of inexact conversions.
  Rounding direction control.
  Range-checking with recovery instead of failure: that is, a mode in which
there is always a value returned, even with a huge roundoff error in case of
out of range (this dosen't happen automatically: if you try to convert a
huge long double to a float you can get a coprocessor overflow exception).

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com