Boost logo

Boost :

From: John Maddock (John_Maddock_at_[hidden])
Date: 2001-11-03 07:46:17

> ...
>I hope you don't mind me putting forward my laundry list in the math
>-> Import the new functions from math.h (this one is a no brainer, I
>think); most of the macros (isgreater, fpclassify, etc.) should really
>be turned into functions/templates (they are macros only because there
>is no overloading in C, and the overloading/template mechanisms are
>better suited to dealing with this functionality: consider: int i;
>fpclassify(i); this probably works, works silently, and can't be
>diagnosed as an error by the compiler.).
>-> Import the missing functionality from complex.h into <complex> (the
>inverse trig and hyperbolic functions, for example); also, any
>functionality in math.h that doesn't currently apply to complex should
>be applied where it makes sense to do so (log10, the gamma family,
>etc.); see also the "future directions" chapter in the C99 standard;
>otherwise, complex.h obvious is superseded by <complex> and shouldn't
>come in.
>-> Floating point environment control in fenv.h should come in
>-> tgmath.h should NOT come in, since the macros are only there to cover
>for the lack of overloading
>-> it would be nice if all the preprocessor macros that define constants
>(HUGE_VAL, INFINITY, etc.) could follow the lead of boost/cstdlib and
>become constant variables.

That all looks very sensible to me - the "function like macros" in C99
math.h really do need to be overloaded functions in C++. Off the top of my
head I don't see any incompatibilities with C either?

BTW the dinkum docs suggest that these are implemented as macros in the
dinkumware lib even for C++ programs.

- John Maddock

Boost list run by bdawes at, gregod at, cpdaniel at, john at