[vtk-developers] Data structures in VTK

[Andy Cedilnik]

Well, we do not really need to wrap templated classes. My though about this 
from the start was to
minimize redundency of the code within VTK and related projects, not to be 
used in TCL, Python,
JAVA, ...  applications. Since templates are already used within VTK, this 
should not be a problem.

find ./ -type f | xargs grep -l "template *<" | wc

shows 116 files that use templates.

In any case, vtkDataArray cannot be used as a universal data array, because 
it can be only used for a very
specific subset of data types. We should not close doors for developers to 
use dynamic arrays or other
containers for arbitrary data type. The reason why we do not have to wrap 
these containers is because
languages that wrap VTK define them by themself. For example Tcl has 
associative array,  java has
hash table, etc. The only bad point is that VTK class cannot return a 
container. When this has to happen,
VTK class could return a fixed sized array or something similar.

So, STL we either include all or nothing. If all, then somebody will need 
to make a serious change of job
from developer to administrator.

                                 Andy

At 08:05 AM 1/2/2002 -0500, Will Schroeder wrote:

>Some other thoughts about templates. A lot of it comes from working with 
>Insight (ITK) which is a very heavily templated code base over the last 
>two years.
>
>+ Wrapping: wrapping templated code/classes into Tcl/Python etc. is nasty. 
>Just ask Brad King at Kitware who has a tool to do it (CABLE). While it 
>works, there are several problems.
>   - The libraries are 2-3x bigger than the current wrappers. (Brad's 
> working on this.)
>   - The build process requires some indication of what types to 
> instantiate. Too many types and you get huge libraries and too many 
> choices at run-time to instantiate.
>   - In ITK we are thinking of creating a typeless class layer so that 
> wrapping is simplified and users can get a better handle on things.
>
>+ STL:
>   - Honestly? I think the STL API is poor. I suspect that it was written 
> by some computer science experts who have never written large, practical 
> applications in their life and had to maintain it for any length of time 
> (including supporting users). I have to admit that it is very useful when 
> it works.
>- There are memory issues, etc. Sometime memory is not released even when 
>you think it should be. In a data-oriented system like VTK you have to 
>have control of when data is released.
>
>+ Templated programming:
>   - We have run into situations where users instantiate classes of a 
> particular type T only to find that the class does not actually function 
> for that T. For example, some filters in ITK only work with floating 
> point arithmetic; instantiate them with short and the results are wrong. 
> Work has to go into guarding against this, and it's not easy to do right.
>
>+ Complexity: the code becomes very complex. C++ programmers with modest 
>skills struggle with the stuff.
>   - Compilers still don't support templated code properly. Partial 
> specialization? forget it on the MS Visual C++.
>   - We are now on the path to removing template parameters from ITK..
>   - The error and warning messages with templated code are unbelievably 
> nasty. It takes a lot of knowledge of C++ to understand
>      what the heck the compiler is telling you.
>   - Templates are oriented towards compile-time usage. Applications are 
> oriented towards run-time usage. The two mix very poorly. In ITK the IO 
> process is very complex because of the mapping of run-time (reading) into 
> compile-time. I think of templated code as being just that: a template 
> for an application. But somebody somewhere has to make the hard decisions 
> as to what template parameters to instantiate in order to create an 
> application. Templated libraries don't do this, they defer the decision 
> to the "application writer."  I find that this is too much of a burden of 
> the user of the toolkit. I like the fact that in VTK we have made these 
> hard decisions, it makes it much easier to use.
>
>In summary, here's what I'd like to see with templates:
>- A small number of templated VTK classes, maybe DataArray and Collection. 
>A typeless layer (for wrapping) above may be required.
>- The use of STL within classes, only as an implementation tool.
>- No inheritance from STL classes