[Mesa-dev] Mixing C & C++

Paul Berry stereotype441 at gmail.com
Tue Nov 8 12:49:43 PST 2011


On 8 November 2011 12:30, Jose Fonseca <jfonseca at vmware.com> 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
>
>
>
> 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" ...
>
>
A (closed-source) project I worked on in the past had very good luck with a
similar approach to this, however to avoid disruption in the code base,
rather than change all of the .c files to .cpp, we simply changed the
makefiles so that all source files were built as C++.  It might be worth a
try here to ease the transition.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20111108/183ccff3/attachment-0001.htm>


More information about the mesa-dev mailing list