[Insight-users] destruction of smart pointers

[dean.inglis@on.aibn.com]

Hi James,

I tried the within scope pointer destruction
as a test to see if the pointer would in fact
unregister/destruct.  My dilemma is that 
initializing an itk member pointer in a BCB form's 
constructor can be done, but on exit from the
application the form destructs and the itk pointer
appears to try to free itself after!

The only case when this does not occur is when
an itk pointer is declared and initialized within
the scope of the form's constructor and the itk pointer's register count is incremented to maintain it existence.  However, this means that one cannot
use the pointer's name beyond the scope of the 
form's constructor.

Can anyone else verify this behaviour with a simple
BCB GUI app?

thanks,
Dean 
> 
> From: "Miller, James V (Research)" <millerjv@crd.ge.com>
> Date: 2003/02/17 Mon AM 09:10:30 GMT-05:00
> To: "'dean.inglis@on.aibn.com'" <dean.inglis@on.aibn.com>, 
>    insight-users@public.kitware.com
> Subject: RE: [Insight-users] destruction of smart pointers
> 
> There are very few places in ITK where we call UnRegister() on 
> a SmartPointer.  Essentially, this is the beauty of the SmartPointer
> implementation is that you do not need to remember to unregister
> your hold on an object.  When the SmartPointer goes out of scope,
> UnRegister() is called automatically.
> 
> What is happening in your example, is that the call to UnRegister()
> is deleting the underlying object and then when the SmartPointer goes
> out of scope (at the end of the program) it tries to delete it a second
> time.
> 
> I imagine if you change your code to never call UnRegister(), you will be
> fine.
> 
> Example #1:  Scope releasing memory
> 
> {  
>    ImageImportType::Pointer itkImporter
>    itkImporter = ImageImportType::New();
>    itkImporter->DebugOn();
> } // itkImporter goes out of scope here, so it is deleted
> 
> 
> Example #2:  Pointer reassign releasing memory
> 
>    ImageImportType::Pointer itkImporter
>    itkImporter = ImageImportType::New();
>    itkImporter = 0;  // Pointer assigned to itkImporter is overwritten, 
>                      // so underlying object is deleted if reference count
> was 1
> 
> 	
> For your ITK example 
> 
>    vtkPtr = 0;
>    vtkPtr = vtkSomeClass::New();
>    vtkPtr->Destroy();
>    vtkPtr = 0;
> 
> the equivalent ITK code would be
> 
>    itkPtr = itk::SomeClass::New();
>    itkPtr = 0; // pointer overwrite automatically causes UnRegister to be
> called on the 
>                // original object.
> 
> 
> 
> > -----Original Message-----
> > From: dean.inglis@on.aibn.com [mailto:dean.inglis@on.aibn.com]
> > Sent: Saturday, February 15, 2003 11:09 PM
> > To: insight-users@public.kitware.com
> > Subject: [Insight-users] destruction of smart pointers
> > 
> > 
> > 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
> > 
> > _______________________________________________
> > Insight-users mailing list
> > Insight-users@public.kitware.com
> > http://public.kitware.com/mailman/listinfo/insight-users
> > 
>