[Mesa-dev] Mixing C & C++

[Kenneth Graunke]

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

Yeah.  This was pretty simple when all the C++ code lived in a single
directory...but now that it's started creeping into core Mesa, it's
getting to be more of a tangled mess.

I'm normally not a fan of .hpp/.hh for headers, but my past experience
was on pure-C++ or pure-C projects.  So it wasn't confusing.  Using a
different extension to differentiate might be helpful here.

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

Sadly, this isn't strictly true: C99 adds some features that aren't
technically in C++.  For example, named structure field initializers.
That said, I believe both GCC and Clang allow those, and we already have
to avoid them in core Mesa for MSVC.  So it may not be an issue...

Other issues we'd run into:
- C and C++ handle enum/int conversions differently.
- C++ requires explicit casts when assigning from void *pointers.

On the plus side, we wouldn't have any "all the declarations need to be
at the top" issues, nor any "for (int i = 0; ...)" issues.  So we'd
probably break MSVC less often.

> But this would probably be even more disruptive than adding extern "C" ...
> 
> Jose

Yeah.  It would be disruptive, but may cause less trouble in the long
run.  I don't know...