[vtk-developers] Virtual methods in VTK classes

[Will Schroeder]

Hi Charl-

BoxWidget is a relatively new addition (as are most of the widgets). As 
John B. said, in many cases the methods are not virtual because the 
implementor(s) of the class did not forsee subclassing, etc. Since we are 
breaking new ground with the widgets (i.e., we have no pre-existing 
implementation to compare with) I expect that things like this will 
continue to evolve.

The place to watch for virtuals is methods that are used in tight loops 
(e.g., GetPoint(), GetCell()). After making this mistake more than once and 
now having decent compilers on hand, I try to use templating whenever 
possible in this situation to avoid performance problems. So if you are 
going to modify a method to become virtual--and it's used in a tight 
loop--you'll want to bounce it off the list and think about the performance 
problem. Otherwise, I'd go ahead and make the changes.

Will

At 01:03 PM 7/1/2003 +0200, Charl P. Botha wrote:
>Dear developers,
>
>Is there any kind of policy with regards to virtual methods in VTK
>classes?  Are there any fundamental problems with making more of the
>base methods virtual?
>
>At the moment, I'm looking at vtkBoxWidget.h for instance.  Most of this
>class's methods are non-virtual, meaning that deriving from vtkBoxWidget
>to create a specialised box widget is near-impossible.
>
>I would appreciated any comments on this, especially relating to whether
>there would be problems virtualising some of the base methods.