[Insight-developers] Function hooks in itk::ProcessObject: ( function pointers vs virtual methods)
Miller, James V (CRD)
millerjv at crd.ge.com
Tue Sep 12 17:03:22 EDT 2000
I don't think "B" really limits what can be done in these callback functions. I usually use a static
function and pass "this" as the arg data. My static function then casts the arg to right data type
and starts calling member functions of the class. This methodology has serve me pretty well for the
past 10 years (ever since I wanted to rig an X callback to a C++ function).
However, I think Bill Hoffman's idea sounds intriguing. This is something that we should look in to.
-----Original Message-----
From: Luis Ibanez [mailto:ibanez at cs.unc.edu]
Sent: Tuesday, September 12, 2000 11:30 AM
To: insight-developers at public.kitware.com
Subject: [Insight-developers] Function hooks in itk::ProcessObject:
(function pointers vs virtual methods)
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 this
functions.
A possible better way to implement these hooks is just as
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
More information about the Insight-developers
mailing list