Re: [boost] New Boost.XInt Library, request preliminary review

Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-03-30 10:04:01

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/30/2010 07:15 AM, Stewart, Robert wrote:

>>> Existing code may rely on getting a NaN, or may rely on
>>> *not* getting a NaN. Policies allow users to decide.
>>
>> Exactly what I was intending with the exception-blocking
>> mechanism.
> 
> Your approach involves runtime cost, I think.  Policies allow
> altering the implementation, at compile time.

Which isn't necessarily the best way to do it, and certainly isn't the
only one. There is effectively zero runtime cost for XInt's
exception-blocking mechanism, since the code used for it is only
evaluated when an exception needs to be thrown.

Perhaps you're thinking of the earlier comment that having a
Not-a-Number value in the library involves some runtime cost. That's
true, but the cost is so minimal (one comparison to zero for each
integer-type parameter to a function) as to be unnoticeable -- a handful
of clock cycles per function in the very worst case. If that's a
problem, I can reduce it even further, but I don't expect anyone will be
able to show that it is.

> How does one mix code wanting exceptions with code not wanting them?
> With policies, the two types differ, but can be designed for
> interoperability.

And with XInt's exception-blocking, nothing differs except the behavior.
- -- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuyBNAACgkQp9x9jeZ9/wSpaACcCPYXh15ZMbGx6eU1VxTH4tLj
pUAAnjbUGY1mGiB621B3it3GpnxM4DOy
=Dra8
-----END PGP SIGNATURE-----