RE: Contents of <confdefs.h> for C++

[Jan Reimers]

Walter,
        Try thinking of a way to use the namespace feature in C++. Here is a
kludge that may get you over the hump:

namespace std {
#include <confdefs.h>
};

Now all the stdlib.h rubbish is in the std namespace.  But I think the
preprocessor defines will not be.

This is indeed what namespaces are for.

JR

> -----Original Message-----
> From: Walter E. Brown [mailto:address@hidden
> Sent: Friday, July 05, 2002 8:40 AM
> To: Paul Eggert
> Cc: address@hidden
> Subject: Re: Contents of <confdefs.h> for C++
> 
> 
> Thanks, Paul, for the courteous and quick response.
> 
> Suppose my program defines entities whose names clash with names
> declared in <stdlib.h>.  While it is certainly arguable whether this
> constitutes good practice, it seems equally certain that such programs
> comply with the relevant language standard(s).
> 
> (As an example, suppose I want my own rand() function.  Although
> valid, such a program will fail to compile in C when a header
> introduces a name clash.)
> 
> This situation is potentially much worse in C++, because C++ permits
> overloaded functions.  This means that I can write a
> correctly-behaving, fully-compliant program whose behavior may
> nonetheless be different when <stdlib.h> is part of the program.
> 
> (Permit me to generalize for a moment:  Suppose I have some function
> f(), taking a double parameter.  If my program invokes f(3), my
> function is called because 3 will be converted to 3.0.  However, if an
> included header defines a function f() that takes an int parameter,
> then f(3) will call the header's f(int), not my f(double)!  Thus, my
> program will still compile, yet exhibit potentially different
> behavior.)
> 
> Because of such issues, it is important in my context that I have full
> control over which headers are included.  I believe this is not
> unreasonable.
> 
> However, there may be compelling reasons for autoconf's current
> behavior; I will reserve judgement until I learn more about its
> underlying rationale in this regard.  I had begun to look at the
> source code, as suggested, and do understand the mechanics of the
> macro you mention, but not yet the reasoning behind them; there seems
> to be special concern about the exit() function, but that's all I
> really know at the moment.
> 
> Thanks again,
> 
>     - WEB
> 
> 
> ----- Original Message -----
> From: "Paul Eggert" <address@hidden>
> To: <address@hidden>
> Cc: <address@hidden>
> Sent: Friday, July 05, 2002 12:21 AM
> Subject: Re: Contents of <confdefs.h> for C++
> 
> 
> > > From: "Walter E. Brown" <address@hidden>
> > > Date: Thu, 04 Jul 2002 16:01:53 -0500
> > >
> > > This unwanted and seemingly undocumented "feature" is deadly to
> many
> > > of my C++ test programs, as it forcibly introduces extra symbols.
> It
> > > messes up my testing in other ways, too.
> >
> > Details, please?  Why can't you write your test programs so that
> they
> > are robust in the presence of "#include <stdlib.h>"?
> >
> > > At a minimum, can someone kindly provide the rationale behind this
> > > "feature" so that, perhaps, other possibilities can be explored?
> >
> > You might look at the source code for autoconf, e.g. at
> > _AC_PROG_CXX_EXIT_DECLARATION.  (I haven't a clue as to why
> <stdlib.h>
> > is being included, but then again I avoid C++ so I have an excuse
> for
> > being clueless.  :-)
> 
>