Subject: Re: [boost] Second iteration of Boost.XInt library uploaded, requesting further comments
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2010-04-01 09:59:45
> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] On Behalf Of Stewart, Robert
> Sent: Thursday, April 01, 2010 12:26 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Second iteration of Boost.XInt library uploaded, requesting further comments
> Chad Nelson wrote:
> > On 03/31/2010 01:26 PM, DE wrote:
> > > i find 'nan()' member function confusing
> > > i would have made 'nan()' a static function returning NaN
> > > and renamed the former to 'is_nan()'
> > > similarly 'odd()' and 'even()' could be 'is_odd()' and
> > > 'is_even()' but these are less confusing to me [...]
> > The nan function was named that way because it fits in with the naming
> > of the even and odd functions (which n1694 specified). For what it's
> > worth, I agree with you; the constructor taking a not_a_number object
> > was my second choice, not my first.
> There's still time to change the upcoming standard and you can lead the way now in your library. Consider submitting
defects for these things to make future code more readable.
But the existence of N1694 doesn't mean it is in any way 'Standard'- it is just a suggesting to the WG21 standards
They didn't rule it out (I think that they were much too busy with other more pressing matters like getting the C++0X
standard defined), but they didn't endorse it.
is_nan, is_inf ... is part of the C99/TR1/C++0X Standard for *floating-point*, so it would seem only logical to follow
If we are allowing a NaN then testing and copying sign would also seem useful.
But let's let Chad get something that everyone can play with in the sandbox first?
--- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk