[Mesa-dev] Mixing C & C++
Jose Fonseca
jfonseca at vmware.com
Tue Nov 8 12:30:36 PST 2011
At the moment MSVC build's failing with the error
mesa.lib(uniform_query.obj) : error LNK2001: unresolved external symbol "int MESA_VERBOSE" (?MESA_VERBOSE@@3HA)
build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll : fatal error LNK1120: 1 unresolved externals
and trying to fix seems a to be deep rat hole. Clearly extern "C" is missing, but what surprises me is that this works on Linux.
One problem is that putting enclose #includes inside extern "C, like:
extern "C" {
#include "foo.h"
}
is non portable, because "foo.h" may include system headers, some of which often have
#ifdef __cplusplus
// Helper C++ class
class Foo {
};
#endif /* __cplusplus */
and C++ code inside extern "C" is an error.
That is, all our .h headers that will also be included by .C++ files should follow the following pattern:
// includes (but no declarations)
#include <boo.h>
#include "foo.h"
....
#ifdef __cplusplus
extern "C" {
#endif
// type/function declarations here (but no includes!)
struct aaa;
typedef int bbb;
...
#ifdef __cplusplus
}
#endif
Second, it would really help to clearly distinguish headers that are meant to be used exclusive by C++ with a different suffix (e.g., .hpp). And leave .h for headers that are meant for joint C/C++ consuption.
Take e.g., ../glsl/program.h, are these supposed to be C functions or C++ functions? There's no way to tell just from reading the headers. So it's not clear if those type/functions should be inside extern "C" {..} or not.
Is this OK?
Another approach that would avoid all these extern "C" would be to all Mesa source files to .cpp. A part of a few reserver symbols and type strictness, C is a subset of C++. But this would probably be even more disruptive than adding extern "C" ...
Jose
More information about the mesa-dev
mailing list