Some issues with mixing C and C++ 1

[WebDrake]

I've started introducing some C++ modules to my code project (scientific number-crunching), where it's convenient to do so, and have been following the instructions at

http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html

for mixing code.

A few things are niggling me, mostly trivial, but here goes...

(1) [Annoying niggle] I've been modifying header files for C modules by surrounding them with,

#ifdef __cplusplus
extern "C" {
#endif

/* Header stuff */

#ifdef __cplusplus
}
#endif

Unfortunately including the line [tt]extern "C" {[/tt] causes all editors I've encountered to want to indent everything that follows. Any way to stop this? I considered just defining a couple of things, [tt]#define BEGINexternC ...[/tt] and [tt]ENDexternC[/tt], but is there something simpler I can do?

(2) [tt]bool[/tt] and [tt]_Bool[/tt]. In C code I've used the [tt]_Bool[/tt] type because I don't particularly feel the need for the convenience of calling things "true" or "false". What's wrong with just saying 1 and 0? However, C++ seems to really dislike any sign of _Bool, even in header files surrounded by [tt]extern "C" { ... }[/tt]. So I presume just switching [tt]_Bool[/tt] to [tt]bool[/tt] and including [tt]stdbool.h[/tt] is the way out? Any issues I should be aware of?

(3) [Compiler question.] Is it necessary to use the different commands [tt]g++[/tt] and [tt]gcc[/tt] when compiling C++ and C respectively, or will [tt]gcc[/tt] sort this out by itself? So far I've worked by defining two different compilers in my Makefiles,

CC = gcc
CppC = g++

Many thanks!

 

[xwb]

1) You could do this

#ifdef __cplusplus
#define EXTC extern "C"
#else
#define EXTC
#endif

EXTC whatever

#undef EXTC

It is only required for functions. THe names are mangled in C++ and this stops the name mangling. If everything is correctly prototyped and compiled as C++ then you don't need extern "C" at all. Other than your bool problem, you should be able to compile all C code as C++ provided you're not using special C99 features.
2) 1 and 0 can be confusing for maintenance. For instance, if you had something like

added = 1;

To the reader, this could be a count of how many were added or a flag that something had been added. The former might add or subtract from added whereas the latter would invert it. Yet another coder might use bit patterns and do strange things with it. To be absolutely sure, declare it as bool and use it as such. One technique I've used is

#ifdef __cplusplus
#define BOOL bool
#else
#define BOOL _Bool
#endif

and declare everything as BOOL

3) Since you have stdbool you're possibly using the C99 std. If your program is C89 compliant, you could use g++ for everything. If it is a mix, you'll have to keep them separate or set some compile flags.

 

[WebDrake]

Other than your bool problem, you should be able to compile all C code as C++ provided you're not using special C99 features.

Well, C++ doesn't like [tt]malloc()[/tt] statements much, unless they're cast. :-(

With C I compile with the flags [tt]-ansi -pedantic -Wall[/tt], so, the strictest C89 compatibility (I believe?).

Regarding your suggestion for the [tt]extern "C" {[/tt] problem, I think I'll still have the same annoying unwanted indentation...

To be absolutely sure, declare it as bool and use it as such.

Sure. I do declare these things as [tt]bool[/tt]. In the case of [tt]_Bool[/tt], I can't use [tt]true[/tt] and [tt]false[/tt] because they are not defined in C except via the [tt]stdbool.h[/tt] header (right?).

Your [tt]#ifdef[/tt] suggestion is quite interesting but I would have thought this would be more appropriate:

#ifndef __cplusplus
#include <stdbool.h>
#endif

Which recognises that the header is superfluous if the code is compiled as C++. Then either way I can use [tt]bool[/tt] throughout.

I imagine your method would be superior in situations where you can't trust the person compiling the code to have an up-to-date compiler, though.

Thanks very much for the useful thoughts. :-D

 

[xwb]

Yes - I forgot about having to cast malloc. I've been using C++ since 1988 (before the std came out) that I'd forgotten that you didn't have to cast malloc in C. I used to not cast it before I started using C++. Since then I've always casted malloc.