Archived

This topic is now archived and is closed to further replies.

Lestat3D

casting function pointers

Recommended Posts

how can I cast a "typedef VOID (ClassName::*FunctionName)(VOID*)" function pointer to a "typedef VOID (*FunctionName)(VOID*)" function pointer? what exactly do the "reinterpret_cast" keyword? thnx.

Share this post


Link to post
Share on other sites
You can cast whatever you want to whatever else you want. The question is whether it will make any sense. Casting a method function pointer to a "naked" function pointer will give you problems because the methods use different calling conventions, meaning the method function pointer takes an additional "hidden" parameter (the this pointer).

I''d advise you refactor your design. What exactly are you trying to do?

I wanna work for Microsoft!
[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
I''m trying to encapsulate the WNDCLASS structure within a CWindow class, but I want to put the WndProc function within that class too, and when I try to assign the WindowProcedure to the WNDCLASS it gets the error "cannot cast function...".
What should I do now?
thnx.

Share this post


Link to post
Share on other sites
While we''re on the subject, I just submitted an article on this very topic. Hopefully it''ll be approved and posted soon. It also covers creating a message map technique so individual messages can be handled (and the handlers replaced) dynamically at runtime.

I wanna work for Microsoft!
[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites

Hmm... What would be the use of "dynamically switching
message handler"? That''s what virtual functions are
for. Maybe in C, but since you''re talking about class
memeber functions, I assume you''re talking about C++.


Premature optimizations can only slow down your project even more.

Share this post


Link to post
Share on other sites
quote:
Original post by tangentz
Hmm... What would be the use of "dynamically switching
message handler"? That''s what virtual functions are
for.

Yeah, but then I''d have to derive from the base class just to add a single message handler (for a special control, for example). I''d rather simply write what needs to be written - the specific message handlers - and change the base class properties to reflect the nature of the control.

I wanna work for Microsoft!
[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
quote:
Original post by Lestat3D
how can I cast a "typedef VOID (ClassName::*FunctionName)(VOID*)" function pointer to a "typedef VOID (*FunctionName)(VOID*)" function pointer? what exactly do the "reinterpret_cast" keyword?
thnx.


make ClassName::FunctionName static and you should be able
to cast it without any trouble.

Share this post


Link to post
Share on other sites
quote:
Original post by Oluseyi
Yeah, but then I''d have to derive from the base class just to add a single message handler (for a special control, for example). I''d rather simply write what needs to be written - the specific message handlers - and change the base class properties to reflect the nature of the control.



I''m not sure I undertand your reasoning. If you''re writing
a new kind of control, you''ll be deriving a new class
from the base "window", won''t you? Then you just override
the appropriate virtual message handler.

Or do you go back to the base "window" class every time
you discover you need to handle a new type of message?

"Oops, I need to handle WM_NEWEVENT, so I better
go back and change my base window".


Premature optimizations can only slow down your project even more.

Share this post


Link to post
Share on other sites
quote:
Original post by tangentz
I''m not sure I undertand your reasoning. If you''re writing
a new kind of control, you''ll be deriving a new class
from the base "window", won''t you?

Not necessarily. This class is designed so I don''t have to, and so the class doesn''t include more code than the absolute minimum it needs to.

quote:
Then you just override the appropriate virtual message handler.

Rather than deriving class CustomWindow from Window and then overriding Window::OnStrangeEvent (which must be declared and defined in the base Window class), simply define void OnStrangeEvent and call Window::RegisterMessagehandler(WM_STRANGEEVT, OnStrangeEvent) and get on with life.

Capice?

quote:
Or do you go back to the base "window" class every time
you discover you need to handle a new type of message?

Don''t be silly.

I wanna work for Microsoft!
[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
quote:
Original post by Oluseyi
Rather than deriving class CustomWindow from Window and then overriding Window::OnStrangeEvent (which must be declared and defined in the base Window class), simply define void OnStrangeEvent and call Window::RegisterMessagehandler(WM_STRANGEEVT, OnStrangeEvent) and get on with life.



I cannot say I agree with this decidedly non-OOP design.
But if it works for you, then all is well.

And no, the OnStrangeEvent doesn't need to be declared in
the base window. The base window doesn't need to know
anything about StrangeEvent at all. What you do is in the
derived class HandleEvent (which is virtual), you add a new
case to dispatch StrangeEvent to OnStrangeEvent. Your new
StrangeWindow adds a new virtual function OnStrangeEvent
and "get on with life". All new classes derived from
StrangeWindow now knows how to handle StrangeEvent.

Maybe I'll write an article on an "alternative" (but more
object-oriented) solution and submit to GameDev.


Premature optimizations can only slow down your project even more.

Edited by - tangentz on February 18, 2002 1:36:32 PM

Share this post


Link to post
Share on other sites
quote:
Original post by tangentz

I cannot say I agree with this decidedly non-OOP design.
But if it works for you, then all is well.

And no, the OnStrangeEvent doesn't need to be declared in
the base window. The base window doesn't need to know
anything about StrangeEvent at all. What you do is in the
derived class HandleEvent (which is virtual), you add a new
case to dispatch StrangeEvent to OnStrangeEvent. Your new
StrangeWindow adds a new virtual function OnStrangeEvent
and "get on with life". All new classes derived from
StrangeWindow now knows how to handle StrangeEvent.

Maybe I'll write an article on an "alternative" (but more
object-oriented) solution and submit to GameDev.



This is pretty much how I'm doing it. I totally under stand Oluseyi's point though, too.

The Win32 API is inherintly NON-OO, it's straight C. There's no point in being object-oriented for no other reason than to be object-oriented. You use the best method for handling the given problem at the moment.



"Doomed to crumble, unless we grow, and strengthen our communication" - Maynard James Keenan, Tool

Edited by - daerid on February 18, 2002 1:47:37 PM

Share this post


Link to post
Share on other sites
quote:
Original post by daerid
This is pretty much how I''m doing it. I totally under stand Olu se yi''s point though, too.

The Win32 API is inherintly NON-OO, it''s straight C. There''s no point in being object-oriented for no other reason than to be object-oriented.


This is a common misconception. Yes, it''s true that the
Win32 API is straight C. But just because something is
written in C does NOT mean it is not object-oriented.
You can write "object-oriented" C (not to be confused with
Object-C) quite easily. Especially for environments
where a C++ compiler is not available.

Anyhow, whether the API is C (procedural) or C++ (object-
oriented) is irrelevant. What''s relevant is that GUI
message/event handling *is* inherently object-oriented.
It''s higher-level than the Win32 API and is applicable
to other OS/API/whatever.

I wrote a GUI for GLUT.

quote:
Original post by daerid
You use the best method for handling the given problem at the moment.



This is "short-sighted" programming. If software is
designed for extensibility right from the start, we''d have
much fewer maintenance problems. Object-oriented programming
*is* the right tool for handling the given problem,
which is GUI event/message handling.


Premature optimizations can only slow down your project even more.

Share this post


Link to post
Share on other sites
quote:
This is "short-sighted" programming.


That would be an assumption on your part, sir. It is possible to write extensible non-OO code, just as it is possible to write OO code in C.

I personally don''t believe that OO is the best approach to every single programming challenge out there. You have to take it on a case-by-case basis. I do agree though that GUI and Event handling IS inherintly object oriented.

Share this post


Link to post
Share on other sites