bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Symbol availability in C, C++


From: Paul Eggert
Subject: Re: Symbol availability in C, C++
Date: Mon, 28 Nov 2005 13:04:10 -0800
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

Albert Chin <address@hidden> writes:

> I'm talking about _one_ project with two languages, C and C++. In
> such a project, if human.h includes <stdint.h> because of
> HAVE_STDINT_H, how should a C++ source file #include "human.h"
> correctly when <stdint.h> isn't available to the C++ compiler?

Sorry, you'll have to bear with me because I'm not a C++ expert.

Traditionally, I assume it would be done by having the #include
"human.h" inside an extern "C".  That is, inside extern "C", the usual
C rules apply.

What I hear you saying is that you have a C++/C compiler pair where
extern "C" doesn't actually drop you into a mode that is compatible
with C; it gives you a subset of the C features, one that lacks
<stdint.h>.

One way to fix this, I suppose, would be to have Autoconf test every C
feature in both C mode and in C++-with-extern-"C" mode, and to
consider the feature to be unsupported if either test fails.  This
would require some autoconf hackery but shouldn't affect the source
code.

Another way is to modify every header that is compiled by both C and
C++ compilers, so that the header inspects two sets of feature macros,
one for C and one for C++.  That is a more drastic and global change,
one that I'd rather avoid.  As I understand it, that's the quick
change that you put in.

If <stdint.h> is the main problem here, another fix, and perhaps the
best one, would be to supply a substitute <stdint.h> that is visible
only to the C++ compiler.  That would require less autoconf hackery
(and would also leave the source code alone).




reply via email to

[Prev in Thread] Current Thread [Next in Thread]