On Mon, Nov 28, 2005 at 01:04:10PM -0800, Paul Eggert wrote: > 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.
I'm not sure "the usual C rules apply" is correct. But, I'm nothing close to a C++ expert. I think extern "C" simply means to use the "C" naming convention for symbols (so you don't get C++ name mangling). > 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>. Correct, in the above case. See my initial email for another example with mbstate_t on HP-UX 11.23/IA. > 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. Ick. > 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. I think this solution is more correct. Also, I think we can get away with a minimal set of changes to work around the current list of problems. That's probably good enough. We can always add to this as problems arise. > 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). We tried this with gl_STDINT_H. However, the custom stdint_.h defines uintmax_t which conflicts with gl_AC_TYPE_UINTMAX_T. -- albert chin ([EMAIL PROTECTED]) _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
