[vtk-developers] Containers and... String
Andy.Cedilnik at kitware.com
Tue Jan 22 07:11:14 EST 2002
>A vtkCollection does in fact have ordering. Anyway, I think that
>if VTK gets proper containers then those containers should at the
>very least support basic operators. The operators could even be
>wrapped in Java and Python.
How can you wrap operators in java?
The problem is that (quote) "operators are ambiguous and are not intuitive".
I sort of agree with this, but I would not mind some operators to be there.
>Almost everywhere that a linked list is used, the 'vector' could be
>used instead with little or no loss of efficency.
Hmm, maybe, but I still think this should be let to the developer to decide.
If somebody needs a linked list, we should provide at least the interface for
>You mean a hash table with exactly one value per hash? Just let people
>set the hash function (either make it a virtual method or provide a
Actually no. Array implementation of associative array is not based on
hashing, but on
position matching. Consider an array of pairs. First element in the pair is
a key, second
element is a value. This way you can find find any element in linear time
but it has virtually
>If they are templated, then they are only usable within the VTK classes
>i.e. they can't be wrapped. I suppose this is fine, but I would still
>like to see vtkCollection turn into a proper 'vector' type so that doing
>things like going through the list of all actors in a renderer wasn't
>such a pain.
vtkCollection and such could use internally containers.
>Okay then, vtkString would basically just be a container for a char *
>to provide reference counting and other conveniences. Also if you had
>several actors that were displaying the same text then you could just
>change the contents of the vtkString and all actors would update
>Actually, one thing I would love to see is a massive clean-up of
>vtkDataObject and the subclassing of nearly all 'accessory' classes
>in VTK from vtkDataObject. That way vtkTransform, vtkLookupTable,
>the new vtkString, vtkProperty, etc. could all be pipelined nicely.
>It would be possible e.g. to define a 'base' vtkProperty, and then
>send it through a vtkPropertyFilter which would allow adjustment of
>the color, opacity, ambient etc. so that it would be easy to make
>a set of actors with similar but differentiated properties.
Well, common containers would add severe cleanup to VTK.
More information about the vtk-developers