Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.


#42 UserData defined per-callback


I noticed that the functions "glutSetWindowData"
and "glutGetWindowData" while not documented, are in
fact implimented. These seem like they could be useful
to provide the address of a class with additional
information on the window - such as virtual functions for
display etc.

I recomend the following however:

1) provide user data on a per-callback basis
2) adopt a doxygen commenting style

for example, in C++ a user could type the following


class MyClass {
static void invokeMouseMember(int button, int state,
int x, int y)
state, x, y);


MyClass myData;

or even


or even for c

struct tagMouseData
typedef struct TagMouseData MouseData;

void onMouse(int button, int state, int x, int y)
MouseData* data = (MouseData*)glutGetMouseData



  • Richard Rauch
    Richard Rauch

    Logged In: YES

    My impression is that adding per-callback data the way that
    you suggest would be problematic. It would perhaps be easier
    to have a glutAddCallbackData() which works with the most
    recent callback registered/selected. The window callback
    registration/use is already wrapped in a macro so window
    callbacks would be relatively easy to tinker with that way.
    Non-window callbacks would be more difficult.

    My initial impression, however, is that this is not an
    appropriate change to make.

    A minor nit-pick about the C++ code is that a member function
    (even a static member function) is not quite the same as a C
    function; technically, passing a pointer to such a function
    can break. You should instead pass the function in as an
    {extern "C" { ... }} construct, in order to be perfectly
    correct. This makes C++ code that wants to use a class
    function to handle callbacks from C code a little messy.