vtable problem

[luckiejacky]

boost::shared_ptr<SimObject> pObj = m_simObject;
	if (pObj)
		dynamic_pointer_cast<SimObject>(pObj)->ProcessMovement();

In the code snippet above,
SimObject defines a ProcessMovement method which is virtual....
and CPF_SimObject defines the overrided version of it.

Vehicle is a derived class from CPF_SimObject which doesn't have the overrided method from CPF_SimObject
But m_simObject is simply a SimObject which created off Vehicle
In the above case, I want to call the SimObject::ProcessMovement, which doesn't succeed.

It is still calling the CPF_SimObject version... any ideas why?
Thanks
Jack

[wolle]

The reference to "vtable" suggests you want to surpass the override mechanism of virtual functions?

The best way would be to change the design. Why not just make the base class implementation of ProcessMovement available (under some other name) in the derived classes? You can do this by inheritance or even better, as a free function.

But there is another way I don't recommend. It's called object slicing and is normally considered a trap you fall into by accident. Slicing is when you copy a derived object onto a base object because then the derived part is "sliced away". With your code it would look something like this,

if (pObj) {
    SimObject slice = *pObj; // ugly slicing on purpose, derived part of *pObj object is lost
    slice.ProcessMovement(); // calls SimObject version of function
}

[luckiejacky]

In other words, the preferred way is to give another specific implementation of ProcessMovement for this particular use case....
The first use case is called AStar which find paths in specific way then process the movement in one specific way also
The second use case is called CPF which find paths in another way then process the movement in another specific way

How can I abstract them out?
I have 3 kinds of pathfinders and 3 kinds of ways to process the movements
CPF is a special one, AStar is a normal one
but only one type of SimObject... Maybe I don't bother using a CPF_SimObject which is a specific way
to process movement.... I haven't considered there would be some extensions to this (a new pathfinder and a new way to process it )...
Let's say I have added one more pathfinder to the mess....

[2kaud]

In cases like this it is helpful if you create the simplest possible complete test program that demonstrates the issue. We can then see what is being tried and make suggestions accordingly when can then be tried in the test program until the required outcome is achieved. Once the test program behaves as required then the soultion can then be incorporated into the main program. It's usually easier to try things out in a small test program than in the actual program.

Cheers.

[wolle]

How can I abstract them out?
I have 3 kinds of pathfinders and 3 kinds of ways to process the movements

You don't have to use inheritance to create variation. In fact the second most important rule in object orientation (OO) is: Favour object composition over class inheritance.

So rather than deriving from SimObject you can pass in a PathFinder object and a MoveProcessing object to its constructor when it is created. In this way SimObject will vary depending on how it is composed. You can even change the composition by passing in other PathFinder and MoveProcessing objects. This actually is the State design pattern: Allow an object to alter its behavior when its internal state changes; The object will appear to change class.