Deriving from VTK classes?

Matthew Hall mahall at math.uiuc.edu
Tue Sep 21 12:31:03 EDT 1999


Roland Schwarz wrote:
...
> So I get a pointer, and depending wether it is my derived class or a more
> basic class I want my code to work. Ok, if it is my class I can query
> GetClassName, but what if is an other name? Is it safe to call the function?
> This depends on its position in the class hierarchy. This exactly is what
> dynamic_cast is for.
> 
> In an ideal world I would modify the vtk Library, but I definitely do NOT
> want
> to do this. I am not trying to open Pandoras Box anyway.
> 
> In other words:
> 
> class vtkWindow
> {
>     ...
>     virtual int*    GetSize();
>     ...
> }
> 
> class myCoolWindow : public vtkWindow
> {
>     ...
>     virtual int* GetOrientation();
>     ...
> }
> 
>     ....
>     vtkWindow* window = this->VTKWindow;
>     int* dir = window->GetOrientation(); // oops not in vtkWindow
>     int* dir = ((myCoolWindow*)window)->GetOrientation(); // oops could be a
> vtkWindow
>     ...

Sorry if this is a little late, but it seems to me that the job of
VTK as a library is to provide a general purpose interface to
visualization routines. Adding more exquisite subclasses is good,
but they shouldn't require a library rewrite.

My main point is that it is the _application_ that requests certain
classes, and it is the _application's_ duty to manage those classes (I
know, anthropomorphism galore here) . Consider the (application) code:

vtkSource *aSource = aDataSet->GetSource(); //or whatever it is nowadays

Now, supposing we want to determine the StartTheta of a SphereSource. 
Then we have the same unfortunate situation you described above:

float aSource->GetStartTheta(); //Oops - method not in vtkSource
float ((vtkSphereSource *)aSource)->GetStartTheta(); //Oops, aSource 
				//might not be a SphereSource.

However it would be _ridiculous_ (not to mention dangerous) to require
that vtkSource contain, not only GetStartTheta, but all methods of all 
the subclasses. The app must handle this - not VTK.

Again, since it is the app that will be instantiating your new
orientable
window, it is the app's job to determine which windows are orientable.
If all your windows are orientable, then it is easy (just cast, as in
the 2nd "oops"), otherwise use dynamic_cast, or GetClassName, or some
nifty datastructures to keep track.

This should definitely not be added to VTK for the reason that it would
destroy VTK. (Now a good _user-interface_ framework should have some
sleek way of doing this- see Sebastien Barre's links page for possible
ideas - http://www.hds.utc.fr/~barre/vtk/links.html)

-matt


-----------------------------------------------------------------------------
This is the private VTK discussion list.  Please keep messages on-topic.
Check the FAQ at: <http://www.automatrix.com/cgi-bin/vtkfaq>
To UNSUBSCRIBE, send message body containing "unsubscribe vtkusers" to
<majordomo at gsao.med.ge.com>.  For help, send message body containing
"info vtkusers" to the same address.     Live long and prosper.
-----------------------------------------------------------------------------





More information about the vtkusers mailing list