A trick to wrap the callbacks ???

[Manuel]

I'm trying to write a class for a simple openGL GUI.
I've written a method reshape:

------------------------
void MHwindow::reshape(int w, int h)
{
glViewport ( 0, 0, w, h );
[...]
glLoadIdentity ( );
}
------------------------

In the client code, this should be passed to GLUT, but

------------------------
MHwindow MainWindow();
[...]
glutReshapeFunc ( MainWindow.reshape );
------------------------

don't work:
main.cpp argument of type `void (MHwindow:(int, int)' does not match
`void (*)(int, int)'

However, if in the client code I write:

------------------------
void reshape(int w, int h)
{
MainWindow.reshape(w,h);
}

[...]

glutReshapeFunc ( reshape );
------------------------

it work.

It's legal?
This things is very important for my project.

Thanks,

Manuel

 

[W Marsh]

I'm trying to write a class for a simple openGL GUI.
I've written a method reshape:

------------------------
void MHwindow::reshape(int w, int h)
{
glViewport ( 0, 0, w, h );
[...]
glLoadIdentity ( );
}
------------------------

In the client code, this should be passed to GLUT, but

------------------------
MHwindow MainWindow();
[...]
glutReshapeFunc ( MainWindow.reshape );
------------------------

don't work:
main.cpp argument of type `void (MHwindow:(int, int)' does not match
`void (*)(int, int)'

However, if in the client code I write:

------------------------
void reshape(int w, int h)
{
MainWindow.reshape(w,h);
}

[...]

glutReshapeFunc ( reshape );
------------------------

it work.

It's legal?
This things is very important for my project.

Thanks,

Manuel

A member function pointer isn't at all the same as a normal function
pointer. See the FAQ (there is an entire section on this topic):
http://www.parashift.com/c++-faq-lite/pointers-to-members.html

 

[Manuel]

A member function pointer isn't at all the same as a normal function
pointer. See the FAQ (there is an entire section on this topic):
http://www.parashift.com/c++-faq-lite/pointers-to-members.html

Thanks, I'm going to read.
However, my english is very poor, so I need a lot of time to fully
understand the details of an english text and I'm a C++ newbie too. :-(
Can you, briefly, tell me if it's legal?
If yes, I'll be more motivated to read all...

Thanks again,

Manuel

 

[W Marsh]

Thanks, I'm going to read.
However, my english is very poor, so I need a lot of time to fully
understand the details of an english text and I'm a C++ newbie too. :-(
Can you, briefly, tell me if it's legal?

Legal? I would say no, as what you are attempting to do won't even compile.

You could use a /static/ member function in this way - but as far as I
know it won't be definitely portable (and you won't be able to modify
instance data of your class - it will essentially limit you as much as
your non-member function solution).

You are going to have to design around this. The FAQ suggests wrapping
the object's member function in a non-member function. See if you can
get your head around this portion of the FAQ:
http://www.parashift.com/c++-faq-lite/pointers-to-members.html#faq-33.2

 

[Manuel]

I'm reading...
It seem it's legal:

---------------------------------------------------

Because a member function is meaningless without an object to invoke it
on, you can't do this directly (if The X Window System was rewritten in
C++, it would probably pass references to objects around, not just
pointers to functions; naturally the objects would embody the required
function and probably a whole lot more).

As a patch for existing software, use a top-level (non-member) function
as a wrapper which takes an object obtained through some other
technique. Depending on the routine you're calling, this "other
technique" might be trivial or might require a little work on your part.
The system call that starts a thread, for example, might require you to
pass a function pointer along with a void*, so you can pass the object
pointer in the void*. Many real-time operating systems do something
similar for the function that starts a new task. Worst case you could
store the object pointer in a global variable; this might be required
for Unix signal handlers (but globals are, in general, undesired). In
any case, the top-level function would call the desired member function
on the object.
----------------------------------------------------

I've correctly understand?
thx,

Manuel

 

[W Marsh]

I'm reading...
It seem it's legal:

What do you mean by "it"? Passing a member function pointer when a
top-level function pointer is expect simply won't compile, as you have
discovered. A static member function pointer /probably/ will. As the FAQ
says, a member function is meaningless without an object to invoke it on.

 

[Manuel]

Legal? I would say no, as what you are attempting to do won't even compile.

It compile!
In the first post, I've written:

---------------QUOTE--------------------

[...]
However, if in the client code I write:

------------------------
void reshape(int w, int h)
{
MainWindow.reshape(w,h);
}

[...]

glutReshapeFunc ( reshape );
------------------------

it work.

---------------END QUOTE--------------------

Is this the wrapper suggested by FAQ?
I need to know if this solution is legal.

Regards,

Manuel

 

[W Marsh]

Legal? I would say no, as what you are attempting to do won't even
compile.

It compile!
In the first post, I've written:

---------------QUOTE--------------------

[...]
However, if in the client code I write:

------------------------
void reshape(int w, int h)
{
MainWindow.reshape(w,h);
}

[...]

glutReshapeFunc ( reshape );
------------------------

it work.

---------------END QUOTE--------------------

Is this the wrapper suggested by FAQ?
I need to know if this solution is legal.

Regards,

Manuel

Yes, that is legal code - reshape is a top-level non-member function,
which is what glutReshapeFunc expects. There are no /type/ errors here,
but there may be other errors depending on the state of the MainWindow
object.

 

[Manuel]

Yes, that is legal code - reshape is a top-level non-member function,
which is what glutReshapeFunc expects. There are no /type/ errors here,
but there may be other errors depending on the state of the MainWindow
object.

Thanks!
Of course, errors in MainWindow are possible, however the important
thing is that the base idea is ok in C++ rules.