JUCE Library does exactly what OSG does.
They provide their own typedefs for missing types like GLchar.
But these custom typedefs are contained within the generic 'juce'
namespace and the primary header file contains a 'using namespace juce'
directive.
So these added types are also globally available as the official OpenGL
tyes are.
The difference is now, that the official OpenGL headers are only
included once... no matter how many different frameworks you mix.
But the added custom types like 'GLchar' are provided twice... once by
JUCE and once by OSG, because both headers are included.
The JUCE solution with a 'juce' namespace and a 'using namespace' in the
header file causes everything within the 'juce' namespace to
automatically prioritize its own custom typedefs over the ones from OSG,
although this would theoretically be a collision.
=> no collision if you first include the OSG headers and then the JUCE
headers
If you instead first include the JUCE headers and then the OSG headers
you get dozens of collision errors inside the OSG headers, because
without the typdefs beeing within the 'osg' namespace the compiler does
not know how to prioritize.
juce::GLchar is available because of the 'using namespace' in the JUCE
headers and the OSG GLchar is obviously avaible because it does not use
any namespace.
=> multiple collisions within the OSG headers
If you would move your typedefs inside the 'osg' namespace each
framework would prioritize their own definitions correctly.
Regards,
Benjamin
Am 05.08.2014 20:57, schrieb Robert Osfield:
Hi Benjamin,
On 5 August 2014 19:05, Benjamin Beier <[email protected]
<mailto:[email protected]>> wrote:
some typedefs are not contained within an OSG specific namespace
and therefore cause collisions.
OSG specific typedefs will all be in appropriate namespaces.
The OpenGL typedef's are currently made in the global namespace as per
OpenGL headers and should only be defined when OpenGL headers don't
define them.
One example is 'typedef char GLchar;' in the GL2Extension header,
which causes a collision with the same typname in the JUCE Library.
Fortunately the JUCE Library is using correct namespaces, so i was
able to workaround the problem by reordering the header includes.
Nevertheless this is annoying and should be fixed.
Which namespace is appropriate OpenGL typedefs is not clear cut.
OpenGL itself doesn't use namspaces as it's C. Alas not all OpenGL
headers installed on users machine contain all the definitions so we
have to provide our own as a fallback.
I haven't heard of JUICE library before so can't comment on the
specifics of this library and how it tackles these issue, but if their
are issues with integrating with the OSG it sounds like JUICE library
isn't necessarily honouring the various OpenGL #define's used to
control which typedefs are provided.
OSGs excessive use of preprocessor constants which never respect
namespaces can also easily lead to problems, although the
probability is lower.
OSG pre-processors almost always have an OSG_ or similar prefix.
Feel free to be specific with the exceptions to this.
--
As a general note the OSG is across many platforms and alongside may
other toolkits with very few reports of namespace pollution issues so
it's not something that is a big issue, any changes required to
appease minority opinions will need to considered alongside issues of
backwards compatibility.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
