[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Contents of <confdefs.h> for C++
From: |
Walter E. Brown |
Subject: |
Re: Contents of <confdefs.h> for C++ |
Date: |
Fri, 05 Jul 2002 17:38:02 -0500 |
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. :-)
> >
> >
>
- Re: Contents of <confdefs.h> for C++, (continued)
- Re: Contents of <confdefs.h> for C++, Raja R Harinath, 2002/07/05
- Re: Contents of <confdefs.h> for C++, Walter E. Brown, 2002/07/05
- Re: Contents of <confdefs.h> for C++, Raja R Harinath, 2002/07/05
- Re: Contents of <confdefs.h> for C++, Walter E. Brown, 2002/07/08
- Re: Contents of <confdefs.h> for C++, Braden McDaniel, 2002/07/08
- Re: Contents of <confdefs.h> for C++, Walter E. Brown, 2002/07/09
- Re: Contents of <confdefs.h> for C++, Akim Demaille, 2002/07/10
- Re: Contents of <confdefs.h> for C++, Paul Eggert, 2002/07/08
- Re: Contents of <confdefs.h> for C++, Akim Demaille, 2002/07/09
RE: Contents of <confdefs.h> for C++, Jan Reimers, 2002/07/05
- Re: Contents of <confdefs.h> for C++,
Walter E. Brown <=