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

[kent williams]

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.