Re: [boost] Re: Math Functions

From: Kevin Lynch (krlynch_at_[hidden])
Date: 2001-10-11 12:04:30

Eric Ford wrote:
> 
> Another complication...  Tonight I tried a real project using
> std_compat.  While I didn't explicitly include the cmath or math.h
> files, another of the libraries I was using (blitz++) did.  But since
> math.h is protected by defines, it only got included once and hence
> only in one namespace.  Unless boost provides all the libraries one
> could want (very unlikely), I think we'll have to deal with this
> problem.
> 

Yup... I've run into this problem as well, specifically, while trying to
"fix" the broken cstdlib on gcc-2.96 .  <boost/cstdlib.hpp> which
includes <stdlib.h> is included somewhere along the line in one of the
boost headers that I need to include in the test program (I haven't
tracked it down, but it is probably in boost.test), which means that by
the time I get to trying to load the "compatibility cstdlib.hpp", the
include guards have already kicked in, preventing me from placing the
contents of stdlib.h into namespace std_compat/std.

At this point, I don't know how to avoid the general problem that some
library might include a header file that we need to get at.   Blitz is a
good example of such a library: not only does it unconditionally include
math.h (it might load cmath immediately before loading math.h as well,
on certain platforms), but it also unconditionally includes stdlib.h
(and not ever cstdlib !!!), which means that on platforms where cstdlib
is simply a namespace std wrapper for stdlib.h, the following two pieces
of code will produce stunningly different sets of errors and missing
declarations:

#include <blitz.h>
#include <cstdlib>

and 

#include <cstdlib>
#include <blitz.h>

Furthermore, on platforms where cmath DOESN'T simply wrap math.h in
namespace std, the following code from blitz.h will result in many names
appearing in both std and at global scope:

#ifdef BZ_MATH_FN_IN_NAMESPACE_STD 
  #include <cmath>
#endif

#include <math.h>

In any case, your point is well taken; the current approach of
attempting to "fix" broken cmath and cstdlib headers is going to fail
miserably when faced with other libraries and the header file include
guards.  Time to go back to the drawing board, I guess.  Any ideas? 
Clearly, whatever approach we take is still not going to work with all
arbitrary libraries on all arbitrarily chosen platforms; I think we just
need one that: 1) works on as many platforms as possible and 2) does not
require changes to the system's files (no requirement that users replace
/usr/include/math.h with something we provide).  I don't have a clue how
to resolve this without a major league complication of std_math.hpp. 

> I can solve the problem by undef'ing the symbol defined at the top of
> math.h.  However, this may not be considered kosher.  Additionally,
> this probably requires undef'ing different symbols for each compiler.
> Another annoying complication.
> 

I'm not too pleased with the thought of violating the include guards;
they are usually there for a reason.  Again, I'll have to spend some
time thinking about this and see what I can conjure up....

-- 
-------------------------------------------------------------------------------
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
-------------------------------------------------------------------------------