Albert Chin <[EMAIL PROTECTED]> 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). _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
