[vtkusers] Serious(?) flaws in vtk code

[Per Dalgas Jakobsen]

Hi all,

I believe I have found some flaws in the vtk code.
I think most vtk users are not affected, but us poor souls that are forced to use Borland C++ Builder (BCB) are affected.

The problem reveals itself the following way (in my case at least):
Access violation in the destructor of vtkPolyData (~vtkPolyData) - The DummyCritSect.Lock() call fails.

The cause is that DummyCritSect, in certain cases, has already been destroyed. In other words: ~vtkPolyData is calling a method in an object that is no longer in existence.

Explanation:
DummyCritSect is a "nonlocal" object which is created before main() is executed, and destroyed after main() has returned. This is actually what is intended, and quite nice, except when used from within (but not exclusively) BCB...

The problem is that the Visual Component Library (VCL), which is the foundation of BCB, also seems to be created from a "nonlocal" object. This means that BCB Windows and DummyCritSect are created at the same point, and destroyed at the same point, but the sequence is undefined.

According to "The C++ Programming Language" by Bjarne Stroustrup:
-------
Section 10.4.9 Nonlocal store:

1) "A variable defined outside any function (that is, global, namespace, and class static variables; §C.9) is initialized (constructed) before main() is invoked, and any such variable that has been constructed will have its destructor invoked after exit from main()."

2) "No implementation-independent guarantees are made about the order of construction of nonlocal objects in different compilation units."

3) "The order of destruction is similarly implementation-dependent."
-------

This means that IF vtk is accessed from a "nonlocal" object, it is implementation-dependent wether it works or not. In case of BCB, it doesn't :-(

As long as you are not making components containing vtk-code in BCB, it is possible to make workarounds, but it seems to be impossible to get component-wrapped vtk-code to work correctly.


How do we get around this problem?
I don't think that we should "#ifdef __BORLANDC__" our way out of the BCB problem, this will leave the code flawed for projects using nonlocal objects.
Any thoughts?


Best regards
Per