Jump to content
  • Advertisement

Archived

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

Lestat3D

casting function pointers

This topic is 6026 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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
Advertisement
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 this subject, check this out:

http://www.gamedev.net/community/forums/topic.asp?topic_id=80820

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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!