[Mesa-dev] Mixing C & C++

[Jose Fonseca]

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

Thanks. I'll do the same.

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

We can always rename them back, but .h/.hpp is a lesser issue:  as long as the extern "C" are there  then it becomes evident what language (and name manling) is to be expected. 

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

Yes, I think that standardizing on C++ makes sense on the long term (due to GLSL, LLVM, and general productivity), but a naive rename will be a can of worms.

Jose