[Insight-developers] Returning a smart pointer or a pointer?

[Luis Ibanez]

Hi Kent,

I would suspect that the performance hit comes from the Mutex operation
that is called from the assignment operator of the SmartPointer.

This Mutex is needed for providing thread-safety in the increment and
decrement of the reference counting that accompanies the assignment of
one SmartPointer to another.


     Luis


----------------------
kent williams wrote:
> The general idea of SmartPointers is that if you always use smart pointers
> for dynamically allocated objects, then you don't have to do the memory
> management yourself.
> 
> For backwards compatibility reasons, the return value of
> itk::PDEDeformableRegistrationFunction::GetDeformationField is not going to
> change.
> 
> What this function returns is a handle on an image. I fail to see the case
> where you'd be dereferencing this smart pointer often enough to affect
> program performance. If you are, you probably need to be using
> itk::ImageRegionIterator, or hoist calls to access methods via smart
> pointers outside of inner loops.
> 
> If you really truly do not want to work with SmartPointers, you can always
> get a naked pointer to the object via itk::SmartPointer:GetPointer(). This
> should be done only with the greatest care, as you can end up using the
> naked pointer after all instances of the smart pointer are destroyed, at
> which point your naked pointer points to freed memory.
> 
> The least desirable way to do things is to use raw pointers, but manage the
> reference count explicitly in your code. This is painful, error prone, and
> unnecessary.  There are places inside ITK library code where this is done
> for performance or obscure technical reasons, but you have to really know
> what you're doing to do this.
> 
> On 5/19/08 11:09 AM, "Tom Vercauteren" <tom.vercauteren at gmail.com> wrote:
> 
> 
>>Hi all,
>>
>>Since I am not sure to fully understand ITK's policy regarding the use
>>of smart pointers versus pointers, I would appreciate any feedback on
>>the following question:
>>Why does itk::PDEDeformableRegistrationFunction::GetDeformationField
>>returns a smart pointer and not a pointer and can we change that?
>>
>>
>>The reason I am asking is because I realized that returning a smart
>>pointer was affecting the performance of my application. Changing the
>>return type to a usual pointer led to a measurable speedup.
>>
>>Since most other functions return a usual pointer it seems like
>>itk::PDEDeformableRegistrationFunction::GetDeformationField should
>>also return a pointer. If we change the return type, some users may
>>run into backwards compatibility issues (e.g. a class inherits from
>>PDEDeformableRegistrationFunction but redefines GetDeformationField).
>>This seems unlikely though...
>>
>>
>>Thanks,
>>Tom
>>_______________________________________________
>>Insight-developers mailing list
>>Insight-developers at itk.org
>>http://www.itk.org/mailman/listinfo/insight-developers
> 
> 
> 
> 
> Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
> 
> 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>