[Insight-users] destruction of smart pointers - more

[dean.inglis@on.aibn.com]

Ok, the call stack shows:

004042AE itk::SmartPointer<itk::VTKImageImport<itk::Image<float,2>>>::UnRegister(this=:09FF2FE0)
00404220 
itk::SmartPointer<itk::VTKImageImport<itk::Image<float,2>>>::~SmartPointer<itk::VTKImageImport<itk::Image<float,2>>>(this=:09FF2FE0)
00404886 TForm1::~TForm1(this=:09FF2CE4)
0046A96D Classes::TComponent::DestroyComponents
0048DB17 __init_exit_proc
0048DB66 __cleaup
0048CE28 _exit
0048DD3C ___startup

Does this mean that after the class that owns the
itk pointer object (as a class member) is destroyed,
the smart pointer, which should not exist, is trying
to destroy itself???

Dean

> 
> still trying to get Borland GUI working here.
> I did a simple test: in my Form class definition 
> I have in the public section:
> 
> typedef itk::Image<float, 2> ImageType;
> typedef itk::VTKImageImport<ImageType>
> ImageImportType;
> ImageImportType::Pointer itkImporter;
> 
> in the Form's constructor, I try to create and
> then immediately destroy the pointer:
> 
>   itkImporter = ImageImportType::New();
>   itkImporter->DebugOn();
>   itkImporter->UnRegister();
> 
> the Win32 OuputWindow shows the Reference count goes
> to zero and the pointer destructs.  However, after
> running and then exiting the app, the debugger shows
> the line 
> 
>   void UnRegister()
>     {
> ***->    if(m_Pointer) { m_Pointer->UnRegister(); }
>     }
> 
> in itkSmartPointer.h as being the cause of an access
> violation.  Is there some other itk object that
> need to be destroyed that I am missing? I am stumped ... but am determined to  get GUI development working with BCB5 and ITK!
> Can someone explain to me the difference(s) in 
> terms of object persistence/lifetime between
> typical class pointers and SmartPointers. i.e.,
> if it were a VTK class object:
>  vtkSomeClass* vtkPtr;
> 
> one can do this: 
>   vtkPtr = 0;
> and
>   vtkPtr = vtkSomeClass::New();
> and 
>   vtkPtr->Destroy();
> and maybe again
>   vtkPtr = 0;
> 
> One always 'knows' what one is getting in terms of
> pointer validity/existence.  How does this compare
> with itk smart pointers?  Perhaps its obvious, but
> I need to be hit on the head here ...
> 
> Dean