[vtk-developers] Data structures in VTK
Will Schroeder
will.schroeder at kitware.com
Wed Jan 2 08:05:44 EST 2002
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
Will
At 08:55 AM 1/1/2002 -0500, Simon Warfield wrote:
>On Mon, Dec 31, 2001 at 10:54:40AM -0500, Bill Hoffman wrote:
> > This comes up every once and a while. VTK has several link-lists,
> arrays and
> > hash tables scattered about the code. Every once and a while, someone
> comes along,
> > and says, hey we should centralized these classes so they are not
> duplicated which is
> > obviously bad. Then it is said that we should not do that because
> these classes are
> > too hard to write, and STL will save us. However, every time we try
> to use STL in
> > a project, it becomes a maintenance/portability nightmare. STL pushes
> compilers to the limit.
> >
> > In Insight, we are now including an ENTIRE copy of STL and the stream
> library in the source
> > CVS tree because ONE systems compiler does not ship with a thread safe
> version of those
> > libraries.
>
>I'm not clear on the problem. Is it a bad thing that you didn't need to
>implement a portable thread-safe container library but could instead just drop
>in one of the existing packages ?
>
>I think the system you are refering to is SGI. What is the problem with SGI
>iostreams and threads anyway ?
>Here is SGI on thread safe STL:
>http://www.sgi.com/tech/stl/thread_safety.html
>
> > I have a fear that if we adopted STL in VTK, within a month we would
> not only be
> > maintaining a list, array and hash table class, but rather an entire
> implementation
> > of the c++ standard library (as we have done for ITK).
>
> Would it be wrong to select a c++ standard library and drop it in as a third
>party library ? It would be exactly the same as VTK current does with
>tcl or python.
>
> > Not even taking the thread issue into consideration, with cmake, it has
> been very difficult
> > to support some of the compilers as VTK uses. (have a look at
> cmStandardIncludes.h in cmake)
> >
> > So the question is how long should VTK wait. If it is more than a
> year, then I think
> > it would be better to consolidate the existing containers scattered
> about VTK, then just
> > saying that we should use STL when it works, and not fixing the
> existing problem of duplicated
> > container code.
> >
> > -Bill
> >
> > At 01:41 PM 12/28/2001 -0500, Lorensen, William E (CRD) wrote:
> > >Certainly we should look at STL. For example, I believe that CMake
> uses some stl. Insight (the NLM
> > >toolkit) uses it heavily, but does have some portability problems.
> > >
> > >For example, SGI does not ship an STL that is thread safe. (OK the
> story is longer than that).
> > >For Insight, we have to build a development from SGI.
> > >
> > >It takes a long time to get these sorts of things right. I would
> discourage any more STL like classes
> > >in vtk.
> > >
> > >Bill
> > >
> > >-----Original Message-----
> > >From: Prabhu Ramachandran [mailto:prabhu at aero.iitm.ernet.in]
> > >Sent: Friday, December 28, 2001 1:27 PM
> > >To: vtk-developers at public.kitware.com
> > >Subject: Re: [vtk-developers] Data structures in VTK
> > >
> > >
> > >>>>>> "SW" == Simon Warfield <warfield at bwh.harvard.edu> writes:
> > >
> > > SW> Does it really make sense to continue to avoid using STL ?
> > >
> > > SW> If vendor STLs are still too incompatible and not compliant
> > > SW> with the standard, then one option would be to use a drop in
> > > SW> replacement for vendor STL such as STLport
> > > SW> http://www.stlport.com/product.html
> > >
> > >Yes, with more than 20 different compilers being supported it is
> > >certainly unfair to say STLport is not cross platform. However, maybe
> > >the biggest worry is that by adding STLPort VTK will rope in another
> > >dependency, which might not be desired. So unless compilers ship with
> > >a working STL it might not make sense to use STL. That said, I find
> > >it hard to believe that STL is not standard enough today.
> > >
> > >prabhu
> > >_______________________________________________
> > >vtk-developers mailing list
> > >vtk-developers at public.kitware.com
> > >http://public.kitware.com/mailman/listinfo/vtk-developers
> > >_______________________________________________
> > >vtk-developers mailing list
> > >vtk-developers at public.kitware.com
> > >http://public.kitware.com/mailman/listinfo/vtk-developers
> >
> > _______________________________________________
> > vtk-developers mailing list
> > vtk-developers at public.kitware.com
> > http://public.kitware.com/mailman/listinfo/vtk-developers
>
>--
>Simon Warfield, Ph.D. warfield at bwh.harvard.edu Phone:617-732-7090
>http://www.spl.harvard.edu/~warfield FAX: 617-582-6033
>Assistant Professor of Radiology, Harvard Medical School
>Thorn 329, Department of Radiology, Brigham and Women's Hospital
>75 Francis St, Boston, MA, 02115
>_______________________________________________
>vtk-developers mailing list
>vtk-developers at public.kitware.com
>http://public.kitware.com/mailman/listinfo/vtk-developers
More information about the vtk-developers
mailing list