The use of a local enum does help make the API a bit more explicit in terms of what is valid/vs invalid data to pass to it object when setting it up, as GLenum is bascially just a int with a massive number of associated #define in the OpenGL library, with the no external association between types and the functionas that are associated with - you have to learn these associations from reading OpenGL texts.
For a minimal and complete implementation would probably cut these enums out completely, but I'm hesitant to go this route. Especially as the enum often can help standardise of what can be a whole history of OpenGL enum i.e _EXT, _ARB etc.
As for you particular task I'm not sure what to recommend.
Robert.
On 10/2/06, Hartmut Seichter <
[EMAIL PROTECTED]> wrote:
Hi osgDevs,
while working on osgBindings I stumbled across things like this:
class OSG_EXPORT BlendFunc : public StateAttribute {
...
enum BlendFuncMode {
DST_ALPHA = GL_DST_ALPHA,
DST_COLOR = GL_DST_COLOR
...
}
inline void setFunction( GLenum source, GLenum destination )
...
(every method using GLenum)
and the member variables:
GLenum _source_factor;
GLenum _destination_factor;
GLenum _source_factor_alpha;
GLenum _destination_factor_alpha;
Is this intentional? Why are enums been generated (nice) but then not
been used? I know it doesn't make a difference for C++ but it makes a
big difference when you bind it to other languages (not using reflections).
Cheers,
Hartmut
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
