Re: [Mesa-dev] Mixing C C++
On 11/08/2011 12:30 PM, Jose Fonseca wrote:
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?
I agree. Pure C++ headers should have the .hpp extension. That would eliminate
some unnecessary confusion.
--
Chad Versace
c...@chad-versace.us
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mixing C C++
On 8 November 2011 12:30, Jose Fonseca jfons...@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.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mixing C C++
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) #includeboo.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++.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mixing C C++
- 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) #includeboo.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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mixing C C++
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...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
