Code:
Code:

shared_ptr<Human> sph( new Staff );
shared_ptr<CommandBase> cp = new Command<Human>(spf, ...);

I don't understand this.
This and the example just before it simply indicate that if you're going to prepare for a call to a function in the Staff class, the Command that's fashioned has to be a Command<Staff>, however (this snippet) points out that even if the object IS a Staff, if the target function is really in Human (it's base), the command can be fashioned Command<Human>, if it's convenient.

1. What is the usage of command factory ?
The command factory idea is simply a simpler interface for making commands. It can help make the registration of commands a little easier. Template class instantiations require full types - the compiler can't deduce based on context.

Command<TargetObject> c( o, &TargetObject::function );

However, a template function in the command target, or some other template function (non-member) can deduce based on context, so that can be made a little simpler. If (as is likely) the Command<T> is stored by some non-template base (CommandBase for example), the factory might be used thus:

shared_ptr<CommandBase> = CreateCommand( o, &TargetObject::function );

The template function "CreateCommand" (it could be non-member, it could be static, it could be a template function member of a commander class) can deduce the template parameter for creating a Command<T>, the base of which is something like CommandBase.

Code:
2. How to initialize the command list member command with a sequence of command which can handle different type ?
"Different type" - I'm not sure I understand; I think this can mean a different type of target object who's member function is to be called, it could mean the function signature is a different type (returns something, takes a parameter).

For the first....there's a second question to ask. You said you want to call by number. That's fine, what does this number represent?

It could be that there is a command list such that a single integer represent a command call - that command call "knows" the target object and function to be called.

On the other hand, it could be that the command list is structured by type - such that you must specify two integers, an object type and a function ID - one integer represents the target object type to call, the other the function within that object.

Both of these imply that for any command there is only one target object, and the command knows that target object.

This further implies that if there were, say, 5 target objects of the same type, and one function to be called, there would be 5 command objects, each one representing the same member function for each of the 5 target objects. This may be appropriate if the population of target objects is always small.

On the other hand, it is entirely reasonable to want a command system that allows you to select functions for any target object. This target object can be supplied at the time the call is required (this is more complex and flexible - I don't yet sense this is your interest).

In any event, if you form a command list based on a non-template base (CommandBase for example), then storage is from that common viewpoint (the container need not know the target object types, they can be a mixture of any target objects).

A virtual funtion in CommandBase (likely pure virtual) suffices. The child template Command<T> responds, know the type and likely the actual object upon which the call is based.


3. What is the type to command list or commander ?

Assuming CommandBase is a simple non-template with a virtual "callback" function - and the "real" object instantiated is a Command<T> derived from CommandBase, the command list could be a simple as...

vector<shared_ptr<CommandBase> > a;

...The shared_ptr means the "real" type of each entry can be virtual. You can't store virtual objects in

vector<CommandBase>....

The vector can't accept Command<T> in such a container.

I envision the commander is a class which owns the command list (it would be a member of that class), and may provide other conveniences for making the generic calls, registering - whatever general operations represent the concept of commands.

4. What is the usage of GenericCommander base class since there is no polymorphism involved ?
First, there is polymorphism there.

However, I've been a bit careless with names. I respond occasionally on a laptop without my notes (I have, for example, a VS2008 project of your name with some examples I've used to proof some of the code snippets, but at the moment I'm on a laptop attending my son's swimming lesson, my notes aren't with me, and I'm typing in a stream of thought - so my choice for class names are a whim).

CommandBase == GenericCommander

Command<T> == Commander<T>


You'll note there's a virtual function in GenericCommander called ExecuteSignalCallback. This is a generic interface.

vector<shared_ptr<GenericCommander> > commandlist;

This list would not "know", from this perspective, what target objects or functions are involved. It can do this....

commandlist[2]->ExecuteSignallCallback();

The child version of that function, in Commander<T>, "knows" the type of the object being called.

There's something missing though (Did I type Commander<T> in your post?)....

I don't see the function body there.....it would need a shared_ptr<T> upon which to base the function call...



Oh, I see - you titled it - your code so far...

Out here in the bright sun, a laptop screen isn't easy to read ....


I'll check back later today to see if I've missed something significant.