From: Ed Brey (brey_at_[hidden])
Date: 2001-05-14 13:35:29
From: "Jens Maurer" <Jens.Maurer_at_[hidden]>
> If the macros are being used on an implementation-level, that is fine
> with me. I doubt that "C" people will download boost, though, because
> it is announced as a "collection of C++ libraries". Thus, we may miss
> this user group entirely.
I tend to agree. It would seem to me that a generated C header file,
while useful, should really be submitted to some organization besides
boost. However, others have argued for inclusion in boost. I'd like to
hear the rational from those people as to why having a consilidated
C/C++ math library outweighs the cleanliness of having the library
content match its housing organization. The argument I'd be interested
in seeing refuted is this: We could include other languages besides C
and C++. Clearly, no one thinks that would be the right approach. So
then, why C, just because it's a closer relative?
> Derived constants are required for optimal precision, because (e.g.)
> pi/3 potentially has less than "double" precision when evaluated.
I still don't have a good handle on home much precision is gained by
writing out the literal versus having the compiler compute it at
compile-time? That gain needs to be traded off against the cluttering
of the interface. And then even if there is a gain, what is its value
if you only get it for the derived constants that happen to be built in
to the library? This reminds me of the problem with using tailored
(hand-crafted binary) constants. Somewhere along the way, the user is
likely to need a constants that isn't provided, and if he really needs
that kind of precision, he's going to have to writing in precalculated
values anyway. At that point, he's only about as well off as if he
entered all the constants himself in the first place.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk