Jump to content
  • Advertisement
Sign in to follow this  
SiS-Shadowman

Pointer to class functions

This topic is 3912 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

I've got a question regarding pointers to class functions. I've written a simple GUI for my engine. It supports callbacks for several events (onclick, onmousover, etc...). The GUI along with my engine is inside a spererate dll. My application then creates the GUI from within another the module. But this way prevents the usage of templates within the GUI, because it just doesn't know the classes of the application. Is there a way to call functions to unknown classes from within the GUI & engine module? Maybe I could provide a basic class that will be inherited by the classes of my application, but I'm unshure if it's a good idea.

Share this post


Link to post
Share on other sites
Advertisement
when setting your callback, you will just have to create a functor object via boost::function and bind it's first parameter to the instance of the class on which it operates. Your GUI subsystem just get a functor and does not have to know anything about the underlying class.

Share this post


Link to post
Share on other sites
To call a classes member function you need the address of the function and an instance of the class on which the function is to be called. Is that what you mean?

Share this post


Link to post
Share on other sites
Quote:
Original post by DaveTo call a classes member function you need the address of the function and an instance of the class on which the function is to be called. Is that what you mean?

I'm worried about that I can't call the function of a class, of wich I don't know the declaration.

Quote:
Original post by Mawww
when setting your callback, you will just have to create a functor object via boost::function and bind it's first parameter to the instance of the class on which it operates. Your GUI subsystem just get a functor and does not have to know anything about the underlying class.


Ok, I'll try this out. Would be perfect in my case, thanks :)

Share this post


Link to post
Share on other sites
You cannot call if you don't know the declaration... no of parameters return type.
'->*' and '.*' operators

class C
{
int Foo(char*){...};
};

typedef int (C::*p_FN)(char*);

main()
{
C c;
C* pc = &c;

p_FN ptr2foo=C::Foo;

//
// to call you need a ptr to the obj
//
((pc)->*(ptr2foo))("bla");
//
//or
//
((c).*(ptr2foo))("bla");
}




http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc13cplr034.htm

Share this post


Link to post
Share on other sites
What I do for my engine GUI is very simple, and does not require any explicit function pointers for event handling.

I just have one class, Screen (you can call it Widget if you like), which has virtual functions like Render, Update, OnDeserialize, OnSerialize, OnMove, OnSize, OnMouseMove, OnLButtonDown, OnKeyDown, OnKeyPress, etc.

The engine calls those virtual functions in response to events. Render() is called from Engine::Render, Update is called from Engine::Update, OnMove is called when Screen's position gets modified; OnMouseMove, OnKeyDown and other input events are called by code in EngineWndProc (because engine subclasses client window). In the Screen class, default processing is done in response to those events.

However, the client can choose to subclass that Screen class, and create, for example ScreenTextbox. Then client can overload OnKeyDown virtual function to make the text box respond to key down events, and client could also overload Render virtual function to draw textbox's visible text. Because ScreenTextbox will also be referrable to as Screen, you can give Engine the pointer to ScreenTextbox and it will call virtual functions as if nothing happened. But, when those virtual functions are called, your handler code ends up being executed, instead of the default code in Screen.

Share this post


Link to post
Share on other sites
Quote:
Original post by gyula
You cannot call if you don't know the declaration... no of parameters return type.
'->*' and '.*' operators
*** Source Snippet Removed ***

http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc13cplr034.htm


That's not entirely true. It's possible: this proves it.
I've just implemented it. Works great.

Quote:
Original post by ValMan
What I do for my engine GUI is very simple, and does not require any explicit function pointers for event handling.

I just have one class, Screen (you can call it Widget if you like), which has virtual functions like Render, Update, OnDeserialize, OnSerialize, OnMove, OnSize, OnMouseMove, OnLButtonDown, OnKeyDown, OnKeyPress, etc.

The engine calls those virtual functions in response to events. Render() is called from Engine::Render, Update is called from Engine::Update, OnMove is called when Screen's position gets modified; OnMouseMove, OnKeyDown and other input events are called by code in EngineWndProc (because engine subclasses client window). In the Screen class, default processing is done in response to those events.

However, the client can choose to subclass that Screen class, and create, for example ScreenTextbox. Then client can overload OnKeyDown virtual function to make the text box respond to key down events, and client could also overload Render virtual function to draw textbox's visible text. Because ScreenTextbox will also be referrable to as Screen, you can give Engine the pointer to ScreenTextbox and it will call virtual functions as if nothing happened. But, when those virtual functions are called, your handler code ends up being executed, instead of the default code in Screen.

That's a good design, but I would need to rewrite a lot of code, 'cause my system is totally different. I'll just stick to functors, they're perfect in my case.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!