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

[Bill Lorensen]

The change will affect users that create a subclass and override the method.

On Mon, May 19, 2008 at 12:57 PM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>
> Hi Tom,
>
> In general:
>
> a) When the object to be returned is a member variable of the
>   class, then a raw pointer is returned, and preferably a
>   "const" raw pointer.
>
>
> b) When the object to be returned is a newly created object,
>   then a SmartPointer is the preferred method, since it will
>   force users of this class to receive the value in a SmartPointer
>   and will prevent the returned object from "death in transit".
>
>
> Looking at the itk::PDEDeformableRegistrationFunction, the
> returned deformation field is actually hold by a member
> variable of this class, therefore, it seems that it will be
> safe to use method (a) [raw pointer].
>
> Could you run an Experimental build with this change ?
>
> and if goes well, then simply commit the change.
>
> This shouldn't have any backward compatibility implications,
> since any user currently receiving the variable will still
> be able to receive it from a raw pointer.
>
>
>  Luis
>
>
> -----------------------
> Tom Vercauteren 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
>>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>