|
class C1
{
void fx() { }
typedef void (C1::*memberFnPtr)();
void f2()
{
memberFnPtr g;
g = &C1::fx;
(this->*g)();
}
};
See: http://www.parashift.com/c++-faq-lite/pointers-to-members.html[^]
Use with care, because they (usually) mean that there is something about your design that you haven't thought through properly. I can't think of any situation right now where you can't use polymorphism to solve the same problem in code that you own. I haven't encountered any member function pointers in my job yet.
|
|
|
|
|
Member function pointers are really handy when you want to call the same member function on every element of a collection. It's either that or write a shim functor to do the call for you. So instead of:
class functor
{
public:
void operator()( object &obj )
{
obj.A();
}
};
std::for_each( data.begin(), data.end(), functor() );
you can use:
std::for_each( data.begin(), data.end(), std::mem_fun_ref( &object::A ) );
The first form is a real pain in the neck before C++0x as you can't define a local class or use a lamda. Your functor has to be defined "somewhere else" which can lead to a bit of flow interruption when you're reading code (for me anyway, your experience probably differs).
Cheers,
Ash
PS: Pedants please note my argument may not apply if...
- I'm not using a pointer, just taking the address of a member function
- I'm using someone else's (i.e. the standard library's)
|
|
|
|
|
I agree mostly. But I have to comment on the "flow interruption"
std::for_each( data.begin(), data.end(), increase_by_one() );
does not interrupt my reading as does this
std::for_each( data.begin(), data.end(), std::mem_fun_ref( &object::increase_by_one) );
In a code review, you would have an extra component to check of course, but that's another matter.
|
|
|
|
|
True, good naming removes most problems.
Cheers,
Ash
|
|
|
|
|
Consider the class -
class A
{
public:
void One() {}
};Declaring and initializing a member function pointer would be -
void (A::*pmfn)() = &A::One;
Calling the method using the function pointer would be -
A obj;
(obj.*pmfn)(); OR
A* ptr = new A;
(A->*pmfn)();
|
|
|
|
|
The c++ syntax and semantics for pointers to members is admittedly confusing. You have seen the basic rules above. I cannot agree however with some of the statements posted above, especially this one:
Use with care, because they (usually) mean that there is something about your design that you haven't thought through properly. I can't think of any situation right now where you can't use polymorphism to solve the same problem in code that you own. I haven't encountered any member function pointers in my job yet
Consider the inversion of control idiom which is inevitable if designing loosely coupled component systems. Usually, you will want to implement something out of the publisher/subscriber family of patterns, like some sort of event/delegate or signal and slot mechanism. In c++, pointers to class member functions are a very handy way to do that. Fortunately, you do not have to use the "raw" c++ syntax - wise men have been working on that and gave us things like std::tr1::function (skip tr1 for c++0x), or even boost::signal and boost::signal2. Here "delegates" to c++ class member functions are quite easy to use:
namespace SubscriberContext {
class Subscriber {
int mID;
public:
bool FileMenu(void) {
std::out << "FileMenu of object " << mID << " called" << atd::endl;
return true;
}
public:
Subscriber(int pID) : mID(pID) {}
};
}
#include <functional>
#include <vector>
namespace PublisherContext {
class Publisher {
public:
typedef std::tr1::function<bool ()> Delegate;
private:
std::vector<Delegate> mSubscribers;
static void Invoke(Delegate pD) { pD(); }
public:
void Connect(Delegate pD) {
mSubsribers.push_back(pD);
}
void Disconnect() {
mSubscribers.clear();
}
void Publish() {
std::for_each(mSubscribers.begin(), mSubscribers.end(), Publisher::Invoke);
}
};
}
int main() {
using namespace std::tr1;
using namespace PublisherContext;
using namespace SubscriberContext;
Publisher tPub;
Subscriber tSubs1(1), tSubs2(2), tSubs3(3);
tPub.Connect(bind(mem_fn(&Subscriber::FileMenu), tSubs1));
tPub.Connect(bind(mem_fn(&Subscriber::FileMenu), tSubs2));
tPub.Connect(bind(mem_fn(&Subscriber::FileMenu), tSubs3));
tPub.Publish();
tPub.Disconnect();
}
Huh, I just wrote it down without trying to compile, so please, be tolerant... There is more to that than this, therefore I would recommend to have a look at boost::signals. With "naked" std::tr1::functions, like in the example above, you cannot, for example, disconnect one specific stub, since td::tr1::function objects are not comparable. But I hope you get the point.
Cheers,
Paul
|
|
|
|
|
I think (and I might be incorrect on this) that the poster you were originally quoting was saying that you could do the same thing using an abstract base class, one implementation per Delegate in your example. And you'd get about the same separation of concerns as well.
This sort of thing tends to be horses for courses - people who think in OO terms are likely to grab onto using interfaces for everything while people who think in compositional or functional terms will tend to reach for templates.
Cheers,
Ash
|
|
|
|
|
Aescleal wrote: This sort of thing tends to be horses for courses - people who think in OO terms are likely to grab onto using interfaces for everything while people who think in compositional or functional terms will tend to reach for templates.
It's not exactly the same, if you don't mind... With functors of that kind you get a first class object representation of a function, basically grabbing the best of both worlds. If you go the pure OO-way , you define an ISubscriber and end up with a variation of the observer pattern. Then, the components are loosely coupled (by sharing the ISubscriber definition) but they are coupled: The only way to subscribe for the Publisher service is to feed him with polymorphic ISubscriber instances.
With the approach sketched above, the Publisher is not coupled to a consumer of it's services at all - the subscriber only needs to satisfy the signature of Delegate. So the "wire up" part could look like this:
bool LooseSubscriber() {
std::out << "LooseSubscriber called" << std::endl;
return true;
}
int main() {
Publisher tPub;
Subscriber tSubs(0);
tPub.Connect
(bind(mem_fn(&Subscriber::FileMenu), tSubs));
tPub.Connect
(LooseSubscriber);
tPub.Connect
([] (void)->bool {
std::out << "lambda Subscriber called" << std::endl;
return true;
});
}
|
|
|
|
|
I didn't say it was exactly the same - you're preaching to the choir here. As I said you get almost the same separation of concerns - the difference is instead of defining an interface (which subscriber doesn't have to be derived from...) you're using a functor from the standard library.
|
|
|
|
|
Aescleal wrote: you're preaching to the choir
You've got me, I could not resist... We've probably lost the thread starter now, but I just wanted to show him/her that with a little help from the std library, pointers to member functions are easy to use.
Cheers,
Paul
|
|
|
|
|
Hi,
I am facing a problem related to window handle.
I have loaded two different OCXs in different instances of the same container application(OLE Server).
In OnCreate() method of second OCX control I am calling the AfxGetMainWnd()function.
It is called after calling the base class function of OnCreate() method.
Now trying to run both instances simultaneously.
The problem is sometimes AfxGetMainWnd()function returns the pointer to a window of first OCX control which is loaded in the first container instance just before. Why it happens?
Thankx in advance.
Regards,
SUnil
|
|
|
|
|
I have done my code to resize the controls of window when we drag the window..its working fine in normal scenario...
if we un check the option show window contents while dragging in performance settings(MyComputer->properties->advance->performance->Settings) of windows.
my window controls are not getting resized any method to over come this....thanks in advance
|
|
|
|
|
where did you place the code to resize the controls? If its is in OnSizing(), try by moving it to OnSize(). Check ::Iswindow() on any of the controls before resizing them, since OnSize will be called once before the child controls are created.
|
|
|
|
|
See if the Extras section of this article helps.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Hi developers, i try to write a file in binary format. But that file is not in binary format, i dont know what's wrong in my code
#include <iostream>
#include <fstream>
using namespace std;
int main()
{
fstream file("file path", ios_base::binary | ios_base::in);
char buf[] = "BinaryFile";
file.write(buf, sizeof(buf));
file.close();
}
Thanks in Advance
|
|
|
|
|
You have posted the same question twice; you already have an answer here[^]
|
|
|
|
|
Hi developers, i try to write a file in binary format. But that file is not in binary format, i dont know what's wrong in my code
#include <iostream>
#include <fstream>
using namespace std;
int main()
{
fstream file("file path", ios_base::binary | ios_base::in);
char buf[] = "BinaryFile";
file.write(buf, sizeof(buf));
file.close();
}
Thanks in Advance
|
|
|
|
|
ganesh_IT wrote: fstream file("file path", ios_base::binary | ios_base::in);
Shouldn't the above line be
fstream file("file path", ios_base::binary | ios_base::out);
?
ganesh_IT wrote: char buf[] = "BinaryFile"
You're writing a bunch of ASCII characters to a binary file, i.e. you're creating, by definition, a ASCII text file.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
ganesh_IT wrote: using namespace std;int main(){ fstream file("file path", ios_base::binary | ios_base::in); char buf[] = "BinaryFile"; file.write(buf, sizeof(buf)); file.close();}
if file exist, it will over right it.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
Hi!
I've to create a Menu System. I wrote a class for Initial Menu page(which contains 4 buttons) and another class for the next page(e.g when clicking the options button in the initial Menu page). I've crated an object of the second class inside the corresponding button's click event at the first class. Similarly I've created an object of the first class inside the back button's click event of the second class. I've created the device(device is necessary to display the gui elements) at each class's constructors. So my second menu page is loaded in a separate window(device). What to do to load it in the same window?
|
|
|
|
|
I don't think it's a good design to create a new instance of a menu page every time a menu button is clicked. Think what will happen if the user repeatedly clicks Options, Back, Options, Back, ...
IMO it would be better to just exit from a menu if the back button is clicked, returning to the event handler that created that page in the first place. This way you can reuse your instances, and also easily keep you state / settings.
Now a question for you: What GUI system are you using? Win32 windows / MFC / OpenGL with home made menus / etc. It's impossible to answer your question without this information.
|
|
|
|
|
I'm using Irrlicht Engine.
|
|
|
|
|
You need to be a bit more specific in your problem descriptions. Are you using a irr::gui::IGUIWindow? What did you try? Do you have a small code snippet to share, showing your problem?
PS. There is a specific irrlicht forum here[^]. They might be better at answering your questions.
|
|
|
|
|
This is my initial Menu class.
#include <irrlicht.h>
#include "../include/InitMenu.h"
#include "../include/OptionsMenu.h"
#include <stdio.h>
#include <stdlib.h>
using namespace irr;
using namespace core;
using namespace video;
using namespace gui;
using namespace io;
using namespace scene;
class COptionsMenu;
InitEventReceiver::InitEventReceiver(SInitMenuContext &context):initMenuContext(context)
{
}
bool InitEventReceiver::OnEvent(const irr::SEvent& event)
{
if (event.GUIEvent.EventType == gui::EGET_BUTTON_CLICKED)
{
s32 idBtn = event.GUIEvent.Caller->getID();
switch(idBtn)
{
case PLAY_BUTTON:
return true;
break;
case OPTIONS_BUTTON:
{
COptionsMenu *optMNU = new COptionsMenu();
optMNU->runGame();
initMenuContext.device->closeDevice();
return true;
break;
}
case CREDITS_BUTTON:
return true;
break;
case EXIT_BUTTON:
initMenuContext.device->closeDevice();
break;
return true;
default:
return false;
}
return true;
}
return false;
}
CInitMenu::CInitMenu()
{
IrrlichtDevice* device = createDevice(video::EDT_DIRECT3D9,core::dimension2d<u32>(640,480),16,false,false,false,0);
dev = device;
int width = 180;
int height = 50;
int x = (device->getVideoDriver()->getScreenSize().Width - 200)/2;
int y = 100;
SColor WHITE = video::SColor(255,255,255,255);
SColor BLUE = video::SColor(255,0,0,255);
gui::IGUISkin* skin = device->getGUIEnvironment()->createSkin(EGUI_SKIN_TYPE::EGST_WINDOWS_METALLIC);
skin->setColor(gui::EGDC_BUTTON_TEXT,WHITE);
skin->setColor(gui::EGDC_WINDOW,BLUE);
device->getGUIEnvironment()->setSkin(skin);
device->getSceneManager()->loadScene("Data/experimentalMenuSystem/Shop.irr");
device->getSceneManager()->addCameraSceneNode(0,core::vector3df(0,100,0),core::vector3df(0,0,100),-1,true);
m_pPlayButton = device->getGUIEnvironment()->addButton(core::recti(x,y,x+width,y+height),0,PLAY_BUTTON,L"Play");
y = y+height;
m_pOptionsButton = device->getGUIEnvironment()->addButton(core::recti(x,y,x+width,y+height),0,OPTIONS_BUTTON,L"Options");
y = y+height;
m_pCreditsButton = device->getGUIEnvironment()->addButton(core::recti(x,y,x+width,y+height),0,CREDITS_BUTTON,L"Credits");
y = y+height;
m_pExitButton = device->getGUIEnvironment()->addButton(core::recti(x,y,x+width,y+height),0,EXIT_BUTTON,L"Exit");
initMnuContext.device = device;
initMnuContext.m_pPlayButton = m_pPlayButton;
initMnuContext.m_pOptionsButton = m_pOptionsButton;
initMnuContext.m_pCreditsButton = m_pCreditsButton;
initMnuContext.m_pExitButton = m_pExitButton;
}
int main(int argc, char **argv)
{
CInitMenu* cIMNU = new CInitMenu();
cIMNU->runGame();
}
void CInitMenu::runGame()
{
InitEventReceiver initReceiver(initMnuContext);
dev->setEventReceiver(&initReceiver);
while(dev->run())
{
if (dev->isWindowActive())
{
dev->getVideoDriver()->beginScene(true, true, video::SColor(0,200,200,200));
dev->getSceneManager()->drawAll();
dev->getGUIEnvironment()->drawAll();
dev->getVideoDriver()->endScene();
}
}
dev->drop();
}
This is Options Menu class:
#include <irrlicht.h>
#include "../include/OptionsMenu.h"
#include "../include/InitMenu.h"
using namespace irr;
using namespace core;
using namespace video;
using namespace gui;
using namespace io;
using namespace scene;
OptionsEventReceiver::OptionsEventReceiver(SOptionsContext &optionsContext):OptionsContext(optionsContext)
{
}
bool OptionsEventReceiver::OnEvent(const irr::SEvent& event)
{
if (event.GUIEvent.EventType == gui::EGET_BUTTON_CLICKED)
{
s32 idBtn = event.GUIEvent.Caller->getID();
printf("Button Clicked: %d \n",idBtn);
switch(idBtn)
{
case PROFILE_BUTTON:
return true;
break;
case FAVOURITES_BUTTON:
return true;
break;
case MATCH_RESULT_BUTTON:
return true;
break;
case OPTIONS_BACK_BUTTON:
{
CInitMenu *cInitMNU = new CInitMenu();
cInitMNU->runGame();
OptionsContext.device->closeDevice();
return true;
break;
}
default:
return false;
}
return false;
}
}
COptionsMenu::COptionsMenu()
{
IrrlichtDevice* device = createDevice(video::EDT_DIRECT3D9,core::dimension2d<u32>(640,480),16,false,false,false,0);
dev = device;
int width = 180;
int height = 50;
int x = (device->getVideoDriver()->getScreenSize().Width - 200)/2;
int y = 100;
SColor WHITE = video::SColor(255,255,255,255);
SColor BLUE = video::SColor(255,0,0,255);
gui::IGUISkin* skin = device->getGUIEnvironment()->createSkin(EGUI_SKIN_TYPE::EGST_WINDOWS_METALLIC);
skin->setColor(gui::EGDC_BUTTON_TEXT,WHITE);
skin->setColor(gui::EGDC_WINDOW,BLUE);
device->getGUIEnvironment()->setSkin(skin);
device->getSceneManager()->loadScene("Data/experimentalMenuSystem/Shop.irr");
device->getSceneManager()->addCameraSceneNode(0,core::vector3df(0,100,0),core::vector3df(0,0,100),-1,true);
m_pPlayerProfileButton = device->getGUIEnvironment()->addButton(recti(x,y,x+width,y+height),0,PROFILE_BUTTON,L"Player Profile");
y = y+height;
m_pFavouritesButton = device->getGUIEnvironment()->addButton(recti(x,y,x+width,y+height),0,FAVOURITES_BUTTON,L"Favorites");
y = y+height;
m_pMatchResultButton = device->getGUIEnvironment()->addButton(recti(x,y,x+width,y+height),0,MATCH_RESULT_BUTTON,L"Match Result");
m_pOptionsBackButton = device->getGUIEnvironment()->addButton(recti(0,400,192,458),0,OPTIONS_BACK_BUTTON,L"Back");
optionsContext.device = device;
optionsContext.m_pPlayerProfileButton = m_pPlayerProfileButton;
optionsContext.m_pFavouritesButton = m_pFavouritesButton;
optionsContext.m_pMatchResultButton = m_pMatchResultButton;
optionsContext.m_pOptionsBackButton = m_pOptionsBackButton;
}
void COptionsMenu::runGame()
{
OptionsEventReceiver optReceiver(optionsContext);
dev->setEventReceiver(&optReceiver);
while(dev->run())
{
if (dev->isWindowActive())
{
dev->getVideoDriver()->beginScene(true, true, video::SColor(0,200,200,200));
dev->getSceneManager()->drawAll();
dev->getGUIEnvironment()->drawAll();
dev->getVideoDriver()->endScene();
}
}
dev->drop();
}
|
|
|
|
|
There are some basic issues with your code.
case EXIT_BUTTON:
initMenuContext.device->closeDevice();
break;
return true;
You don't need both break and return. Especially not in this order. You are only making it harder for yourself to follow the program flow.
This
SColor WHITE = video::SColor(255,255,255,255); is the same as
SColor WHITE(255,255,255,255); Don't type more than you have to to keep readability.
This
CInitMenu* cIMNU = new CInitMenu();
cIMNU->runGame();
will leak memory and should be written something like
CInitMenu().runGame();
even though I think having the main menu as the object root of your app is a bit skewed.
Now, why do you want the new menu appear in the same window? It looks like the GUI system is designed for having child dialogs. An alternative could be to use their tab control.
If you still need to open the menu in the same window, I see no other alternative than to remove (or hide) the original controls, and insert your new ones. But don't take my word for it. I have only seen the GUI classes for about 5 minutes. Ask for a solution in the other forum I gave a link to.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
