[Mesa-dev] Mixing C & C++

[Ian Romanick]

On 11/08/2011 12:30 PM, Jose Fonseca wrote:
> 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

That is completely correct.  We've been really sloppy about that up to 
this point.  I've been trying to clean some of that up as it gets in my way.

> 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.

The problem with .hpp is that sometimes we change our mind.  Previous to 
a recent patch series, glsl_types.h was C++ only.  It is now included in 
C files as well.

> 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" ...

The problem is that all of the DRI drivers use C99 features that are not 
part of C++.