[Insight-developers] Function hooks in itk::ProcessObject: (function pointers vs virtual methods)

[Bill Hoffman]

Inheritance is not always the most convenient way of extending things.
Also, the callbacks are useful as hooks for other languages like tcl
that may not have support for c++ objects.

Perhaps a compromise is to use template callback objects:


class CallBackBase
{
   virtual void Execute() =0;
};

// this object can be passed member function pointers and object pointers
template <class T>
class ObjectCallBack : public CallBackBase
{
   ObjectCallBack(T* object,  
            void (T::*)() memberFunction)
    :THIS(object), m_MemberFunction(memberFunction)
   {}
   virtual void Execute() { 
    THIS->*m_MemberFunction()
    }
T* THIS;
void (T::*)() m_MemberFunction;
};

// This can be used for traditional C style callbacks.
class CCallBack : public CallBackBase
{
   CCallBack(void (*f)(void *), void* arg) : m_Function(f), m_Argument(arg) {}
   virtual void Execute() { (*m_Function)(m_Argument); }
   void (*m_Function)(void *);
   void* m_Argument;
};

//NOTE, some of the syntax may be wrong, but it can be fixed

At 11:30 AM 9/12/00 -0400, Luis Ibanez wrote:
>Hi,
>
>There is a set of hooks for functions on itk::ProcessObject.
>Most of them intended for getting some feedback from the
>state of the process that can potentially be used for GUI.
>
>Among them:
>
>ProgressMethod()
>StartMethod()
>EndMethod()
>
>This is implemented now as a  set of pointers to functions
>of type  :        void  f(void);
>
>In order to plug the particular functions, there are two choices
>
>A) they are standard functions (not methods of any class)
>B) they are static functions of a class.
>
>The first option disrupts a little an Object Oriented design.
>The second limits the kind of things that can be done on these
>functions.
>
>
>A possible better way to implement the hooks is by using 
>virtual methods that can be overloaded in a class deriving
>from the itk::ProcessObject.
>
>So, instead of passing pointers to functions to a particular filter.
>We'll derive the filter and reimplement some of these functions.
>
>The Execute() method will then be able to call all these functions
>in a more natural (and secure) way.
>
>If our particular implementation uses these methods to communicate
>with other classes, the references (or smart pointers) to these
>classes will be stored in the class deriving from itk::ProcessObject.
>
>
>What do you say ?
>
>
>Luis
>
>
>_______________________________________________
>Insight-developers mailing list
>Insight-developers at public.kitware.com
>http://public.kitware.com/mailman/listinfo/insight-developers