Re: Math Functions

From: Kevin Lynch (krlynch_at_[hidden])
Date: 2001-10-02 13:52:53

I'm going to try to respond to multiple comments at once here:

From Darin Adler

> The tradition in boost is to assume "compliant unless known to be
> otherwise". So the symbol should be BOOST_NO_COMPLIANT_CMATH instead.
> Ideally we could find a way to be slightly more specific about what's
> lacking, since "not compliant" is a bit vague.

I agree... I don't really know why I did it the other way around.  After
reading messages other messages, the level of "non compliance" may vary
widely, so working around a noncompliant cmath will likely require as
many different approaches to repair the issues as there are platforms. 
More below ...

Eric Ford wrote:

> This seg faulted for me due to an infinite recursion in some of the
> functions (e.g. cos, fabs) on g++ 2.96.  

Yup.. I found this out sometime after I sent my last email.  After
spending the better part of last night and this morning fighting with
this problem, I have traced it to a gcc bug.  By default, gcc-2.96
ignores std qualification.  All those std:: are just dropped, and the
identifiers are treated as if they are in the global namespace.  You can
change this behavior with the flag -fhonor-std.  However, you then have
issues with most identifiers that SHOULD be in std but are not in
libstdc++ 2  (which is almost everything that is not part of the "STL")
not being found.  So the solution should be to not give it the flag,
right?  WRONG!  For some reason that I can't understand, without the
-fhonor-std flag, gcc is generating completely bogus object code that
either seg faults or goes into an infinite loop (I've traced through the
generated assembly code both with and without the honor-std flag, and
the code is _different_ in those functions that subsequently fail). 
Changing the namespace to something other than std cures the problem,
but shouldn't. 

> For this reason and generally being a good namespace citizen, I think
> putting things in namespace std is probably a bad idea.  
> What about instead using some other namespace which can be an alias to std for
> well behaved cmath headers and can include what you've written for
> non-compliant compilers?

I disagree that putting the missing functions in std is a bad idea
(because the whole idea of cmath.hpp was to arrive at a compliant
<cmath>, requiring injection of missing names into std).  However, since
the REAL goal is to get templatized math functions, come hell or high
water, it seems that the solution may not be to provide a compliance
layer for <cmath>, but to use either your suggested approach of
namespace aliasing, or Fernando's approach of a private conformance
layer.

So, my plan now is to try these various approaches, and attempt to fix
these problems by tomorrow, potentially ditching the idea of fixing
broken <cmath> headers (although I think that I've got an idea that
might make it work on other compilers AND gcc AND get compliant <cmath>
on all platforms, but then again, it might now work).  I'll keep you
apprised of my progress...

-- 
-------------------------------------------------------------------------------
Kevin Lynch				voice:	 [phone]
Physics Department			Fax: [phone]
Boston University			office:	 PRB-565
590 Commonwealth Ave.			e-mail:	 krlynch_at_[hidden]
Boston, MA 02215 USA			http://physics.bu.edu/~krlynch
-------------------------------------------------------------------------------