casting base class ptr into derived to call function ptr

[esrever]

Hello,

I have a layout (simplified) as follows :

template <class T>
class MsgHandler
{
protected :
    typedef void (T::*handle_t)(Message *);
    handle_t _handles[128];
public :
    void procMsg()
    {
                Message * msg = EventMgr::GetMessage();
        (reinterpret_cast<T *>(this)->*_handles[msg->evt()])(msg);
    }
};
 
class Amgr : public MsgHandler<Amgr>
{
public :
    Amgr():MsgHandler(TGT_ALPHA)
    {
        _handles[ALPHA_SET_VAL] = &Amgr::OnChangeInt;
    }
 
    void OnChangeInt(Message * msg)
    {
        ...
    }
};

Question :

I'm worrying about procMsg() in MsgHandler, is it safe to cast the 'this' pointer into the derived class, in order to call a function which *might* affect the derived class variables??

It's the only way I've found that the base class can use the derived class functions, without actually knowing about them and without writing the same code for every class that inherits from MsgHandler.

Thanks in advance,
babis

[weaknessforcats]

The base class can call a derived class method without using a cast if you use
the Hollywood Principle: Don't call us, we'll call you.

This is a design pattern called the Template Method. Here the process is managed
by the base class and tailored by the derived class. It works becaause the access
specifiers (public/private/protected) are ignored when you override functions.

Check this out:

class Parent
{
    private:
        virtual void MethodB() = 0;
    public:
        void MethodA();
 
 
};
void Parent::MethodA()
{
    this->MethodB();
}
class Child : public Parent
{
    private:
        void MethodB();
};
void Child::MethodB()
{
    cout << "You have called Child::MethodB()" << endl;
}
int main()
{
     Parent* obj = new Child;
     obj->MethodA();
}
 

You creat a Child object. The MethodA() that is called is to the Parent object
embedded in the Child. That method calls the virtual MethodB(), which is overridden
by the Child MethodB() so it is the Child MethodB() that is actually called.

The effect is the Parent class called a Child class method.

This design pattern separates the the interface from the implementation.
The interface being the public Parent functions and the implementation being the virtual functions.
This leads to private virtual functions (remember access specifiers are ignored for overriding),
which is the preferred way to design for polymorphism today.

[esrever]

Very interesting pattern, I didn't know..

Problem solved, although all the derived classed now need to override the pure-virtual with the *exact* same piece of code, and all this because of the function pointer requirements, but whatever.. Thanks again!