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-04-01 20:00:59

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

On 04/01/2010 03:59 PM, Scott McMurray wrote:

>> If you mean, you think it was a conscious decision on my part: yes,
>> you're right. That's how I intended it to be used.
> 
> The worry I have is with compound expressions.  It looks nice for a
> single function call, but compare these two lines:
> 
>     w = x/y*z;
>     w = x*y/z;
> 
> With a signalling NaN, their exceptional behaviour is drastically
> different.

That shouldn't be a problem with the new design. If I go with the
exception-blocker system, I've been convinced that the not_a_number
exception should be blockable too, so if exceptions are blocked and you
get a NaN, it will propagate instead of throwing. If they're not
blocked, the library will still throw as soon as it sees one. And of
course, if you're using the core integer, or whatever it's eventually
called, there won't be a NaN value to worry about.

> This is another example of the advantage of the split types: If x, y,
> and z are nothrow_xints, the type of w is what decides whether the
> statement will throw.  Alternatively, if x, y, and z are finite_xints,
> both statements will throw and never touch w.

I haven't had time to delve into your design description (a combination
of real life and professional life have gotten in the way), but I think
I see how that would work.
- -- 
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/

iEYEARECAAYFAku1M7oACgkQp9x9jeZ9/wTPKACcCwT7EjAn/XAOF8q6dMC+hIUt
xq0An1Fv2UwL7HGjnktFd/50LtPd6UMW
=mrSD
-----END PGP SIGNATURE-----