[vtkusers] Too many virtual declaration in vtkCallbackCommand version 1.7.

[David Cole]

In a C++ class library, a "final" class should not be placed in a public 
header file. In VTK, classes that are meant *not* to be derived from are 
typically declared and implemented entirely in an implementation (cxx) file.

I understand your point, but I still think (in general) that more C++ 
library clients might want to derive from vtkCallbackCommand than want 
to minimize absolutely the space that vtables consume. There's only one 
vtable that takes up space for a given C++ class; all instances of a 
given class point to the same vtable. The code that implements a 
function usually takes up much more space than its vtable entry. Even if 
the method were not virtual, its implementation would still take up that 
same amout of space.

Migrating is already often difficult for many reasons; I don't think 
that adding a few virtual methods causes pain. Whenever you upgrade to a 
new build of VTK, you should probably start with an empty binary tree 
(and do a full rebuild of everything).

Did you run into a painful problem (other than a full rebuild) because 
of this or are you just objecting on philosophical grounds?


David


derong wrote:

>I got some points. From my understanding, vtkCallbackCommand is a kind of
>final implementation of vtkComand. A client program can subclass its
>SuperClass(vtkCommand) to have it's own Command implementation. Too many
>virtual declaration will cause more virtual tables in instance to consume
>memory.
>Also it will change memory layout of this class to cause migrating
>difficult. (currently I sticked to use VTK4.2.1, occasionally I checked out
>new vtk to compile against my current application project, it was failure to
>link after this change, I guess that  I have to rebuild all....)
> 
>>From my experiences with using VTK, I like to use vtkCallbackCommand for
>event handling. It's good enough. No need to derive from it to create
>another subclass. 
>
>Previously, I also made some classes that were derived from vtkCommand.
>Although it works,  I never use it again after I know how to use
>vtkCallbackCommand. Also I think it's not good to create a deep level
>subclass. That is my point.
>
>Thx.
>
>
>Dennis
>
>  
>
>-----Original Message-----
>From: David Cole [mailto:david.cole at kitware.com] 
>Sent: Thursday, January 05, 2006 12:11 PM
>To: derong
>Cc: vtkusers at vtk.org
>Subject: Re: [vtkusers] Too many virtual declaration in vtkCallbackCommand
>version 1.7.
>
>Other virtual declarations are not meaningless... They allow for a client
>program to subclass this object and override the behavior of those methods.
>Personally, I'd rather see a C++ library like VTK (meant for further
>subclassing and use by other programmers) err on the side of providing
>slightly too many virtual methods than not quite enough. I absolutely hate
>it when I go to override a method in a library class and discover that it's
>not declared virtual.
>
>Did this change to vtkCallbackCommand actually cause a problem for you? 
>If you have a valid reason for not having virtual methods in that class, you
>could always write your own version of it based on a prior revision of
>vtkCallbackCommand... Fortunately, there's not that much code in that class.
>
>Just my two cents,
>David
>
>derong wrote:
>
>  
>
>>Does anyone take a look at the recent change of vtkCallbackCommand?
>>From my point of view, only Execute(...) needs virtual(comes from 
>>superclass), other virtual declarations are meaningless and not good.
>> 
>> 
>>Dennis
>> 
>> 
>>
>>-----------------------------------------------------------------------
>>-
>>
>>_______________________________________________
>>This is the private VTK discussion list. 
>>Please keep messages on-topic. Check the FAQ at: 
>>http://www.vtk.org/Wiki/VTK_FAQ Follow this link to subscribe/unsubscribe:
>>http://www.vtk.org/mailman/listinfo/vtkusers
>> 
>>
>>    
>>
>
>
>  
>