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

Manuel wrote:[color=blue]
> 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
>[/color]

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-lit...o-members.html

W Marsh wrote:
[color=blue]
> 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-lit...o-members.html[/color]

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

Manuel wrote:[color=blue]
> W Marsh wrote:
>[color=green]
>> 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-lit...o-members.html[/color]
>
>
> 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?[/color]

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-lit....html#faq-33.2

Manuel wrote:[color=blue]
> W Marsh wrote:
>[color=green]
>> 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-lit...o-members.html[/color][/color]

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

Manuel wrote:[color=blue]
> Manuel wrote:
>[color=green]
>> W Marsh wrote:
>>[color=darkred]
>>> 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-lit...o-members.html[/color][/color]
>
>
> I'm reading...
> It seem it's legal:[/color]

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.
[color=blue]
>
> ---------------------------------------------------
>
> 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[/color]

W Marsh wrote:
[color=blue]
> Legal? I would say no, as what you are attempting to do won't even compile.[/color]

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

Manuel wrote:[color=blue]
> W Marsh wrote:
>[color=green]
>> Legal? I would say no, as what you are attempting to do won't even
>> compile.[/color]
>
>
> 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[/color]

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.

W Marsh wrote:
[color=blue]
> 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.[/color]

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