[vtk-developers] Containers and... String

[David Gobbi]

On Mon, 21 Jan 2002, Andy Cedilnik wrote:

>
> >Instead of making a vtkVector class, just expand the vtkCollection
> >class (which is already used all over the place).  I would love,
> >for example, to be able to use the collection[] and *collection++.
>
> Hmm, operators are against the religion the way I see it.
> Collection does not have any ordering information. List on the other hand
> has a very
> strict ordering.

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.

> > >       - vtkLinkedList, which is a linked list implementation
> >
> >Unnecessary as far as I can see, it's probably best not to provide
> >a linked list.
>
> There is a linked list of observers inside the vtkObject. This one could be
> replaced with
> more efficient vtkLinkedList

Almost everywhere that a linked list is used, the 'vector' could be
used instead with little or no loss of efficency.

> > > AssociativeArray contains:
> > >       - vtkHashTable, which is a hash table implementation
> >
> >An efficient hash table would be a very useful thing.
> >
> > >       - vtkTree, which is a (red-black) tree implementation
> >
> >Again, possibly unnecessary.
>
> I don't know about the tree, maybe someday somebody will need it. We can
> leave space for it.
>
> > >       - vtkArrayTable, which is an array implementation
> >I'm not quite sure what this is.
>
> Well, two arrays. I guess linear one-to-one mapping from one type to another.
> Good for simple hashing, where you do not want the overhead of hash table.
> Hmm, maybe unnecessary.

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

> > > vtkContainer class is not subclass of vtkObject, so that we
> > > can use containers inside vtkObject class for things such
> > > as Observers.
> >
> >I would much prefer that the containers are subclassed from
> >vtkObject, so that they can be reference counted etc.  Also,
> >wrapping classes that are not derived from vtkObject is a pain.
> >Finally, I would like it if all the 'items' in the containers
> >are vtkObjects.
>
> We can add reference counting to vtkContainer the same way as vtkCommand
> does it. The problem of container being subclass of vtkObject is that then we
> cannot use containers directly in vtkObject.
> I would also make containers templated so that you can put vtkObject in it
> but you can also put anything you want.

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.

> > > Comments?
> > >
> > > On the side note, I also think we need a vtkSring class.
> >
> >Again, I would like to see this derived from vtkObject.  It should
> >specifically be a 'vtk string', not just a re-implementation of
> >the stl string (re-implementing stl strings would be a rather
> >pointless exercise IMHO).
>
> Well, considering the fact that STL is a no-no for VTK, we can implement a
> simple string class. This one could be a subclass of vtkObject, but as
> said, we cannot use it in vtkObject.

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

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.

 - David