[vtk-developers] VTK containers are gone; long live VTK conta iners

[Brad King]

> Have we gotten around the difficulties of having STL containers in DLLs?

No, but ...

> I thought there were issues with having multiple DLLs having the same
> instantiation of the certain STL containers (list, deque, map, queue)
> due to various static members and Microsoft's "rules" for whose static
> members get used when...

This is an issue with the stl map<> class template for MSVC 6, and it only
happens when two DLLs try to access the same instance of a container
through iterators.  I'm pretty sure accessing separate instances is safe.
Therefore, we must disallow subclasses of a class with an STL ivar from
accessing the container because the classes may be in separate DLLs.  See
below for how this restriction is currently enforced.

> I was under the impression that this impacted not only the ability to
> export STL instantiations but also to export classes that had STL
> instantiations as data members.

This problem is only for public data members, which we don't use.

> Also, does this affect the various vtk*Collection classes?

These will remain untouched, except that the internal implementation may
change to using an STL container.

The idea is that STL can now be used for the implementation of classes,
but NOT as part of the INTERFACE.  All the current places that use it use
the "pimpl" idiom to hide the use of STL in the .cxx file.  As long as an
STL container is used only within a single object file, it cannot have any
DLL problems.

-Brad