[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