[vtk-developers] Data structures in VTK

[Andy Cedilnik]

Hello!

I don't think some primitive containers are too difficult to write. I mean 
the hash
tables and lists that are scattered around VTK tree were probably written in
short amount of time anyway. Let us start selectively and add these classes
to VTK. I suggest we brainstorm the interface that will fulfill everybody's 
needs.

So, for example, I need this in a dynamic array:

Find(x) // finds element x
Insert(i, x) // inserts element x at position i
Append(x)  // appends element x
Prepend(x) // prepend element x
Remove(i) // remove's element at position i
Clean() // removes all elements
Size() // returns number of elements
RealSize() // returns size of internal array

The find is tricky, because you need a comparison function.
All other methods are pretty trivial.
Some other methods:
Sort(i,j) // Sorts the range between i and j
Remove(j,j) // Remove range between i and j
Reverse(j,j) // Reverse range between i and j

and so on. You get the picture.

I vote for developing our own containers. We could potentially use similar 
interface as STL.

                                         Andy

>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 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).
>
>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.