[vtkusers] Serious(?) flaws in vtk code

[John Biddiscombe]

VTK\Examples\GUI\Win32\vtkBorland\ProjectDemo

it's the original Borland demo, which has never been attended to. Please fix
it if you have time. Mind you, now that Borland are dumping BCB, it's worth
discouraging people from adopting it.

JB

----- Original Message ----- 
From: "William A. Hoffman" <billlist at nycap.rr.com>
To: "Xianjin Yang" <Yang at AGIUSA.COM>; <vtkusers at vtk.org>
Cc: "Per Dalgas Jakobsen" <pdj at maridan.dk>
Sent: Wednesday, March 10, 2004 2:13 PM
Subject: RE: [vtkusers] Serious(?) flaws in vtk code


> Where is Project_vtkDemo?  Can it be fixed so other people
> do not run into this problem?
>
> -Bill
>
>
> At 12:32 PM 3/9/2004, Xianjin Yang wrote:
>
> >Dear all,
> >
> >I have been using BCB6 + VTK 4.2 and had similar problems before.
> >To solve Access violation problem related to DummyCritSect.Lock() in the
destructor of vtkPolyData (~vtkPolyData), I did these in the
Project_vtkDemo:
> >
> >1) Remove everything in the FormDestroy event handler.
> >2) Add this FormClose event handler. All problems should be gone!!
> >
> >void __fastcall TVTK_Form::FormClose(TObject *Sender, TCloseAction
&Action)
> >{
> >  if (shrink) shrink->Delete();
> >  vtkTimerLog::DeallocateTimerLog();
> >  vtkWindow1->GetRenderer()->RemoveAllProps();
> >  // VTK_Form->Release();
> >  // Application->Terminate();
> >}
> >I am not sure if the last two lines of code are required in BCB6.
> >
> >vtkTimerLog::DeallocateTimerLog() is a fix discussed here:
>
><http://public.kitware.com/pipermail/vtkusers/2003-August/019522.html>http:
//public.kitware.com/pipermail/vtkusers/2003-August/019522.html
> >
> >Xianjin Yang, Ph.D.
> >
> >
> >
> >-----Original Message----- 
> >From: William A. Hoffman
[<mailto:billlist at nycap.rr.com>mailto:billlist at nycap.rr.com]
> >Sent: Tuesday, March 09, 2004 10:18 AM
> >To: Per Dalgas Jakobsen; vtkusers at vtk.org
> >Subject: Re: [vtkusers] Serious(?) flaws in vtk code
> >
> >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