[vtkusers] Design Gripes

[Murad Nayal]

Rasmus Reinhold Paulsen wrote:
> 

Hi Rasmus,

> Hi Murad,
> 
> I think that you have some good points, but some of your observations are
> and have been discussed in detail especially among the developers. Being a
> newbie myself I have also wondered why templates and the standard template
> library was not used more, but there are some heavyweight arguments
> against it; one of them is that wrapping of templated code is difficult at
> best.

I understand. it is still manageable though. for example the latest
version of SWIG seems to handle templates easily (single template
argument, double+ arguments are tricky). they will still have to map to
separate scripting language classes but that's ok.

> I suggest you to dive into the developer list archives and search for
> articles about containers. I believe that a standard container hierachy is
> currently being implemented and tested in VTK.

will do. thanks for the tip.

Regards

> Regards
> Rasmus
> 
> On Thu, 28 Mar 2002, Murad Nayal wrote:
> 
> > I have been studying vtk4 for a while and I must admit I am finding the
> > design frustrating. I understand the argument that object oriented
> > design principles have to yield to performance considerations when
> > programming visualization applications. I am also aware that the authors
> > have opted not to use advanced features of C++ like templates when these
> > features were not uniformly available in C++ compilers several years
> > ago. but at this point in time does it still make sense to have 5 or 6
> > implementations of data arrays differing by the underlying data type
> > rather than use templates. wouldn't be nice to use the notion of a class
> > Vector3D {float x,y,z; } instead of all the silly float xyz[3] arrays
> > used everywhere. I highly doubt that performance will degrade by using a
> > Vector3D class. Also, it would be really nice if call back functions
> > were function objects that can maintain state. programming with function
> > pointers like void (*)(void*) and associated argument delete functions
> > seems clunky at best. I know there are constraints related to the
> > underlying graphics libraries. but this still could be implemented with
> > no more than an additional indirect function call overhead. would that
> > be so bad for performance? etc..

-- 
Murad Nayal M.D. Ph.D.
Department of Biochemistry and Molecular Biophysics
College of Physicians and Surgeons of Columbia University
630 West 168th Street. New York, NY 10032
Tel: 212-305-6884	Fax: 212-305-6926