Question

If you take an existing C code base and compile it with a C++ compiler, what sort of issues can you expect to crop up? For example, I think that assigning an integer to an value with an enumerated type will fail in C++, whereas it’s legal (if a bit nasty) in C.

If I don’t wrap all my C files in extern C { ... }, am I going to get name-mangling where I least expect it? Is there some reason why I really shouldn’t do this?

For background, we have a very large code-base written in C. For a few years we’ve been jumping through hoops to do things that would come naturally via C++ ( homebrewe inheritance, for example). We’d like to start moving towards C++, but in a gradual fashion; getting our CORBA-like framework to support it, and refactoring modules as we go along to take advantage of the more natural approach C++ would provide.

Answer 1

I’ve done something like this once. The main source of problems was that C++ is more strict about types, as you suspected. You’ll have to add casts where void* are mixed with pointers of other types. Like allocating memory:

Foo *foo;
foo = malloc(sizeof(*foo));

The above is typical C code, but it’ll need a cast in C++:

Foo *foo;
foo = (Foo*)malloc(sizeof(*foo));

There are new reserved words in C++, such as “class”, “and”, “bool”, “catch”, “delete”, “explicit”, “mutable”, “namespace”, “new”, “operator”, “or”, “private”, “protected”, “friend”, etc. These cannot be used as variable names, for example.

The above are probably the most common problems when you compile old C code with a C++ compiler. For a complete list of incompatibilities, see Incompatibilities Between ISO C and ISO C++.

You also ask about name mangling. In absence of extern “C” wrappers, the C++ compiler will mangle the symbols. It’s not a problem as long as you use only a C++ compiler, and don’t rely on dlsym() or something like that to pull symbols from libraries.