[vtkusers] Serious(?) flaws in vtk code

[William A. Hoffman]

I have not looked at the BCB Windows code, however,
it seems that you might be able to move the creation/destruction
of the vtk objects to a different spot.   There must be some method
that is called to initialize the BCB objects, and another one
to destroy them.   You could go to some sort of lazy create if
there is no such method.   Basically, the first time the vtk object
is used, then create the vtk object.  Then when your window gets the
close event, destroy the vtk object, don't just create and destroy the
vtk objects in the constructor/destructor of the BCB object.
All vtk objects should be created after main, and deleted before
the end of main, and you should have no problem.

-Bill


At 04:19 AM 3/9/2004, Per Dalgas Jakobsen wrote:
>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
>
>_______________________________________________
>This is the private VTK discussion list. 
>Please keep messages on-topic. Check the FAQ at: <http://public.kitware.com/cgi-bin/vtkfaq>
>Follow this link to subscribe/unsubscribe:
>http://www.vtk.org/mailman/listinfo/vtkusers