$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: John Maddock (john_at_[hidden])
Date: 2006-07-25 12:53:58
Howard Hinnant wrote:
>> Do we really want to use gratuitously different names from those in
>> C99:
>>
>> isfinite
>> isnorm
>> isinf
>> isnan
>
> If we use the C99 names, do we intend on #undef'ing the C99 macros if
> they exist (C99 says these are macros, not functions)? If we don't
> then the macros will trash our functions. There's an easy technique
> for converting the macro (if it exists) into a function (demonstrated
> by gcc's <cmath>). If we do #undef the C99 macros, this is
> observable behavior which we should document (lest the client be
> testing #ifndef isnan after the boost header gets included).
The way I have it set up is to *not* undef anything, that means you have to
call them using either:
(isnan)(x);
or:
(boost::math::isnan)(x);
Just like we have to do the same thing with min and max already: this usage
is documented with examples as well BTW :-)
> I recommend restricting these templates to floating point types.
> Otherwise they are overly generic, and could easily be called
> accidently, especially isnormal, is_normal, isnorm (or whatever, C99
> and C++0X call it isnormal).
Oh, actually I *need* generic versions of these functions in order to make
parts of the math toolkit I'm working on generic: at the very least these
scale to pretty much anything that has numeric_limits defined, without that
all you can do is assume the number is a zero or a normal: but that's OK too
because most (all?) extended precision types like NTL::RR don't support
infinities or NaN's anyway.
Of course passing a complex number or an octonium or something *would* be a
mistake, but I'm assuming that any function that makes use of isnan etc
wouldn't be compatible with these anyway.
John.