Class method as callback function

I''d be interested in hearing a reply, also, if anyone knows.

Your callback function cannot be a non-static member function of a class. Pointers to member functions are not normal function pointers, and special care must be taken when dealing with them (see some posts about functors in this forum, some days ago). The only possibility you have, if you want Win32 to actually call back a class member function, is to make it static. Static member functions behave like normal function pointers (in fact, they are normal function pointers).

/ Yann

Take a look at this. It works (at least for niyaw ), but you should understand that class member functions use the _thiscall convention.

quote:

---

Take a look at this. It works (at least for niyaw ), but you should understand that class member functions use the _thiscall convention.

---

If Fruny sees this, he''ll get a heart attack...

Quoting niyaw:
"you can put that function into a class and exploit the fact that an __stdcall nonstatic member function without arguments is called identically to an __stdcall global function with one argument, which is the context pointer."

Well... no. This is extremely dangerous. It is 100% compiler specific, how member function pointers are internally handled. The C++ language specifications specifically disallow this, because function pointers to member functions do not necessarily need to be pointers, but can eg. be implemented as offsets. The above code will perhaps work, on a certain compiler, perhaps even only on a certain version of that compiler. Absolutely not recommended.

quote:

---

Original post by Yann L
If Fruny sees this, he''ll get a heart attack...

---

I was about to comment, but Mozilla crashed. So in effect, it did have a heart attack. Thanks for clueing them in - though I doubt it''ll have much effect. *sigh*

To Zipster - I hope you fully understand the meaning of the two leading underscores in __thiscall. If not, well, NOBODY expects the Code Inquisition ! Our two weapons are ...

Yann - Have I become that predictable ?



Documents [ GDNet | MSDN | STL | OpenGL | Formats | RTFM | Asking Smart Questions ]
C++ Stuff [ MinGW | Loki | SDL | Boost. | STLport | FLTK | ACCU Recommended Books ]

now that that code has been brought up twice, i''m in for offense.

consider a typical COM interface.


[i know it won''t compile.] assuming the above code is valid, what''s wrong with my code?

i can think of two things:
1) i use WINAPI instead of STDMETHODCALLTYPE - easily changed.
2) my function isn''t virtual - don''t see this as a problem.

i guess what i''m getting at is that i''m exploiting properties of __stdcall, not some generic calling convention. sure, my code will fail for different conventions, but shouldn''t it always work for __stdcall?

quote:

---

Original post by niyaw
i guess what i''m getting at is that i''m exploiting properties of __stdcall, not some generic calling convention. sure, my code will fail for different conventions, but shouldn''t it always work for __stdcall?

---

Not necessarily. The __thiscall convention may be altered by a compiler vendor, even if __stdcall isn''t due to the huge amounts of C and Pascal code in existence. Basically, you shouldn''t depend on the implementation details of language elements which are specified to be implementation dependent (it''s almost a circular definition!)

Don''t worry ya''ll, I''ve already yelled at niyaw for it being hacky

i ''think'' i found a solution around it..
you can basically create a ''empty'' wndclass function that doesn''t act (just calls defwindowproc)
and another which you call instead of dispatchmessage.
i know it has some disadvantages (you won''t get the initial window creation messages).. but it might be a small solution

quote:

---

Original post by Zipster
Don''t worry ya''ll, I''ve already yelled at niyaw for it being hacky

---

you never had a clue.