>
> If I wanted to declare a pointer to this function:
>
> int foo(int bar);
>
> What would be the syntax for the declaration?
>
> The best I came up with was this:
>
> (int)(*)(int) pfoo = &foo;
>

> int (*pfoo)(int bar)=foo;
>
> If you want to declare an array of function pointers you have
> to do it like this:
>
> int (*pfunarray[])(int bar)={
>         one_fun,
>         another_fun,
>         andsoon_fun,
>         NULL
> };

> <snip>
>
> > Note that int C++ you can only get a pointer to a class member
> > function if it is declared as static (because of the this
> > pointer that otherwise also would be needed).
>
> Nope...
>
> pointers to non-static member functions are also supported (unless you
> use an old version of the M$ C++ compiler)
>
> e.g.
>
> class    FOO
> {
> public:
>             int    xfunc(int, int);
> };
>
> int (FOO::*func)(int, int);
>
> func = &FOO::xfunc;
>
> FOO    some_foo,
>             *foo_ptr;
>
> (some_foo.*xfunc)(1, 2);
>
> (foo_ptr->*xfunc)(1, 2);
>
> Regards
> Sergio Masci

> - What would be the benefit of this compared to just a simple
> - switch/case?
>
> - CSomeClass::HandleState()
> - {
> -        switch (m_iState){
> -        case (STATE_IDLE): StateIdle(); break;
> -        case (STATE_SORT): StateSort(); break;
> -        case (STATE_SORTDONE): StateSortDone(); break;
> -        default:
> -                // handle exception (which function pointers wont) -
>       } -}
>
> -Ruben
>
> Exactly the same as the advantages to using function pointers in the
> non-class, non-member function way for state machines. You don't have
> that ugly switch statement that has to be maintained everytime you add
> a new state. You also don't have to create a separate enumeration type
> for the states. The names of the functions themselves serve that
> purpose.

> On Thu, 12 Dec 2002, Bob Ammerman wrote:
>
> > >Have You ever used pointers to nonstatic member functions? If
> > >so, what was the purpose? I can't see any good reason to use
> > >them, but I am always willing to learn (and I am by no means a
> > >C++ expert:) ).
> >
> > >Regards / Ruben
> >
> >
> > Indeed, and often. I use them for many of the same reasons that I use
> > ordinary function pointers. A simple example would be a class that
> > implemented a state machine where each state was handled by a different
> > member function. You would then use a member function pointer to keep

> > <snip>
> >
> > > Note that int C++ you can only get a pointer to a class member
> > > function if it is declared as static (because of the this
> > > pointer that otherwise also would be needed).
> >
> > Nope...
> >
> > pointers to non-static member functions are also supported (unless you
> > use an old version of the M$ C++ compiler)
> >
> > e.g.
> >
> > class    FOO
> > {
> > public:
> >             int    xfunc(int, int);
> > };
> >
> > int (FOO::*func)(int, int);
> >
> > func = &FOO::xfunc;

> > FOO    some_foo,
> >             *foo_ptr;
> >
> > (some_foo.*xfunc)(1, 2);
> >
> > (foo_ptr->*xfunc)(1, 2);
> >
> > Regards
> > Sergio Masci
>
> Yes, but this would (as You show) require both a pointer to an
> object (or an instance of one) and a pointer to the function.
>
> Have You ever used pointers to nonstatic member functions? If
> so, what was the purpose? I can't see any good reason to use
> them, but I am always willing to learn (and I am by no means a
> C++ expert:) ).
>
> Regards / Ruben

> > I missed some of the posts on this thread so maybe I missed
> something
> > here -- Why would you use pointers to nonstatic member
> functions? Wouldn't
> > it be easier to use pointers to classes that contain
> virtual functions?
>
> This can work quite well. I am assuming you mean that each state is a
> subclass of a generate State class and has a virtual
> 'Execute' method. There
> are however two significant problems with this technique:
>
> 1: Where do you put data needed by the state machine as a whole?
>
> 2: When do you 'new' up a state and 'delete' and old one?
>
> > Or for State Machines, wouldn't it be easier to create a
> State Machine
> > class?

> Consider a SWITCH object that needs to signal another object
> when a given
> switch is opened or closed. You could derive a LAMP object
> from an EVENT
> object that knows about switch_on and switch_off events. Then when the
> SWITCH object needs to signal the LAMP it can do so via the
> correct EVENT
> method. You would then extend the EVENT class to encompass
> all sorts of
> events because you have many components in your system. The
> problem now is
> that your EVENT class must know about all the possible types
> of events that
> can occur AND your event generating objects and your event processing
> objects must agree on the signalling method. This can get
> very messy very
> quickly especially if you want to connect an event generator to an
> incompatible event processor. Say you have a LAMP object that has two
> switches attached one for on/off and the other for full
> brightness / dim.
>
> By using pointers to member functions you can obviate the
> need for a special
> EVENT class, you can get rid of the messy mapping mechanism,
> you end up with
> a succinct solution.
>
> In essence you keep knowledge of the workings of the objects
> better hidden
> from each other, you don't smear the logic halfway across your source.

> Yes I've used and continue to use pointers to member functions quite a
> lot.
>
> I use them particularly when I have some kind of manager object that
> does not know about the object it is managing. You would create the
> manager with the object to be managed together with one or more
> pointers to methods that should be applied depending on some
> condition. While the program is running you might change the method to
> be applied to the managed object. You might do this many times.
>
> Consider a SWITCH object that needs to signal another object when a
> given switch is opened or closed. You could derive a LAMP object from
> an EVENT object that knows about switch_on and switch_off events. Then
> when the SWITCH object needs to signal the LAMP it can do so via the
> correct EVENT method. You would then extend the EVENT class to
> encompass all sorts of events because you have many components in your
> system. The problem now is that your EVENT class must know about all
> the possible types of events that can occur AND your event generating
> objects and your event processing objects must agree on the signalling
> method. This can get very messy very quickly especially if you want to
> connect an event generator to an incompatible event processor. Say you
> have a LAMP object that has two switches attached one for on/off and
> the other for full brightness / dim.
>
> By using pointers to member functions you can obviate the need for a
> special EVENT class, you can get rid of the messy mapping mechanism,
> you end up with a succinct solution.

> implement Macros (a command that maintains a list of other commands to
> execute when called) and undo/redo.
>
> So for you example something like:
>
> *** NOT TESTED OR COMPLETE CODE ***
>
> // Abstract Base Class: Command
> class Command
> {
> public:
>         virtual ~Command();
>
>         virtual void Execute() = 0;
> private:
>         Command();      // Private Constructor
> };
>
> class Light
> {
>         void TurnOn();
>         void TurnOff();
>         bool IsOn();
>         // etc...
> };
>
> class Switch
> {
>         void AttachCommand( Command *pCmd );
>
>         // Call when switch even happens
>         void Invoke() { m_pCmd->Execute(); };
>
> private:
>         Command *m_pCmd;        // Or this could be a list etc..
> }
>
>
> // A Command to turn on a light
> class LightOnCommand : public Command
> {
> public:
>         // when constructed, we will need a target
>         LightOnCommand( Light *pTargetLight );
>
>         virtual void Execute();
> private:
>         Light *m_pTargetLight;
> };
>
> // Implementation of LightOnCommand
> LightOnCommand::LightOnCommand( Light *pTargetLight )
> {
>         m_pTargetLight = pTargetLight;
> }
>
> void LightOnCommand::Execute()
> {
>         m_pTargetLight->TurnOn();
> }
>
> You could also implement a LighOffCommand or a LighToggleCommand
>
> To use (in your manager that sets it all up)
>
> Light ALight;
> Switch ASwitch;
> Command *pCmd;
>
> pCmd = new LighOnCommand( &ALight );
> ASwitch.AttachCommand( pCmd );
>
> ASwitch.Invoke();
>
> This may look like a lot of work, but simple commands that don't need any
> arguments to their targets can be implemented with templates.
>
> The main benefit is that you can easily extend the commands, by adding new
> ones at any time. The Invoker (Switch) doesn't care what they do it knows
> only one interface (Command). The concrete commands (LightOnCommand) can

> tightly coupled to their targets if you really need to (you can have then
> created solely by the target class if you need and so completely hide them
> from the rest of the application).
>
> You can also easily add things like macros and undo/redo.
>
> Cheers,
> Ash.
>
> ---
> Ashley Roll
> Digital Nemesis Pty Ltd
> http://www.digitalnemesis.com
> Mobile: +61 (0)417 705 718
>

>
> Staying with your electrical analogue, Lets say that we now have a motor
> that moves something. It has a "position" that can be set.
>
> Now say we want to have 3 switches, "left", "mid", and "right".
>
> With the pointer method, we would need to implement one of two things:
>
> 1. Add functions to the motor class for "left" "mid" and "right".
> 2. Allow the Switch to store a parameter to pass to a general "move"
> function.
>
> Option 1 is doable, but really is adding extraneous stuff to the motor
> class, do you keep extending this interface each time a new position is
> needed. This is not very elegant, and arguably will cause a maintenance
> nightmare in the future.

>
> With the command pattern, to implement this new functionality is simple.
> There are no changes to the Switch class..
>
> class Motor
> {
>         void Move(int position);
>         // etc.
> };
>
> class MoveMotorCommand : public Command
> {
> public:
>         // when constructed, we will need a target
>         MoveMotorCommand ( Motor *pTarget, int NewPosition );
>
>         virtual void Execute();
> private:
>         Motor *m_pTarget;
>         int m_NewPosition;
>
> };
>
> MoveMotorCommand::MoveMotorCommand( Motor *pTarget, int NewPosition )
> {
>         m_pTarget = pTarget;
>         m_NewPosition = NewPosition;
> }
>
> MoveMotorCommand::Execute()
> {
>         pTarget->Move( m_NewPosition );
> }
>
> Then you can construct as many different switches with different motor
> positions as you like:
>
> Motor     TheMotor;
> Switch  MoveLeftSwitch;
> Switch  MoveRightSwitch;
> Switch  MoveMidSwitch;
> Command *pCmd;
>
> pCmd = new MoveMotorCommand( &TheMotor, 0 );
> MoveLeftSwitch.AttachCommand( pCmd );
>
> pCmd = new MoveMotorCommand( &TheMotor, 128 );
> MoveRightSwitch.AttachCommand( pCmd );
>
> pCmd = new MoveMotorCommand( &TheMotor, 256 );
> MoveMidSwitch.AttachCommand( pCmd );
>
> MoveMidSwitch.Invoke(); // when pressed
>
> Or perhaps you want to implement a switch that turns on a number of

> I think the problem here is that you are locked into the
> virtual method mode of thinking. In which you have a pointer
> to a base class and you want to apply a method to an object
> of a derived class. You see the only way to
> access the method is by having a virtual instance in the
> base. Naturally all overloaded methods must take the same
> parameters. BUT if you scrub the virtual method and point
> directly to the real method, then the name becomes
> just a label AND two methods with the same name in two
> different classes CAN have different parameters and be
> accessed via a pointer to method without conflict.