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

[Walter E. Brown]

Thank you, Jan, for your suggestion.  Alas, it would result in
non-conforming code:  it is not permitted (per 17.4.2.1/3 of the C++
standard) to nest a library header within another namespace.

Nonetheless, I appreciate your kindness in offering assistance.

    - WEB


----- Original Message -----
From: "Jan Reimers" <address@hidden>
To: "'Walter E. Brown'" <address@hidden>; "Paul Eggert"
<address@hidden>
Cc: <address@hidden>
Sent: Friday, July 05, 2002 11:34 AM
Subject: RE: Contents of <confdefs.h> for C++


> 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.  :-)
> >
> >
>