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

[Tom Vercauteren]

Hi all,

I have commited the changes after submitting an experimental build.
PDEDeformableRegistrationFunction::GetDeformationField now returns a
pointer instead of a pointer.

I would also have been possible to have it return a const pointer and
make the method const but unfortunately this would break backward
compatibility.

Thanks for your help,
Tom

On Tue, May 20, 2008 at 9:04 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> The original method probably should have used a Get macro. However,
> the Get macro declares methods as virtual. I guess we just got lucky.
>
> Bill
>
> On Tue, May 20, 2008 at 3:02 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> I agree. If there is no chance of a backward compatibility problem, we
>> should change the current method and remove the new method.
>>
>> Bill
>>
>> On Tue, May 20, 2008 at 2:18 PM, Tom Vercauteren
>> <tom.vercauteren at m4x.org> wrote:
>>> Hi Karthik,
>>>
>>> If there is no real backward compatibility issue, changing the API
>>> would definitely be cleaner and less confusing to the user.
>>>
>>> I actually didn't realize that the method wasn't virtual.
>>>
>>> Tom
>>>
>>> On Tue, May 20, 2008 at 7:19 PM, Karthik Krishnan
>>> <karthik.krishnan at kitware.com> wrote:
>>>> I think tou might as well rework the implementation of the class by
>>>> changing the return type to "DeformationFieldType *" from
>>>> "DeformationFieldTypePointer", instead of adding another
>>>> implementation and deprecating the old one.
>>>>
>>>> Its hard for anyone to be affected by it. The method is not virtual.
>>>> SmartPointers are implicitly castable to raw pointers.
>>>>
>>>> Sure someone can actually override a non-virtual function and get away
>>>> with most compilers but that's pretty stupid.
>>>>
>>>> Chances are by doing so his method won't even be called from the ITK
>>>> framework even now cause it casts classes to
>>>> PDEDeformableRegistrationFunction in the framework.
>>>>
>>>> Am I mistaken ?
>>>>
>>>> Thanks
>>>> --
>>>> karthik
>>>>
>>>> On Tue, May 20, 2008 at 1:20 PM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>>>>>
>>>>>
>>>>> Hi Hauke,
>>>>>
>>>>> Yes,
>>>>> this is what Brad King used to implement the LegacyMacro in VTK,
>>>>> that we then ported to ITK.
>>>>>
>>>>>
>>>>> The macro is in lines 666-680 of the file
>>>>>
>>>>>
>>>>>             Insight/Code/Common/itkMacro.h
>>>>>
>>>>>
>>>>> # define itkLegacyMacro(method) class itkLegacyMethodRemoved /* no ';' */
>>>>> #elif defined(ITK_LEGACY_SILENT) || defined(ITK_LEGACY_TEST) ||
>>>>> defined(CSWIG)
>>>>>  // Provide legacy methods with no warnings.
>>>>> # define itkLegacyMacro(method) method
>>>>> #else
>>>>>  // Setup compile-time warnings for uses of deprecated methods if
>>>>>  // possible on this compiler.
>>>>> # if defined(__GNUC__) && !defined(__INTEL_COMPILER) && (__GNUC__ > 3 ||
>>>>> (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
>>>>> #  define itkLegacyMacro(method) method __attribute__((deprecated))
>>>>> # elif defined(_MSC_VER) && _MSC_VER >= 1300
>>>>> #  define itkLegacyMacro(method) __declspec(deprecated) method
>>>>> # else
>>>>> #  define itkLegacyMacro(method) method
>>>>> # endif
>>>>> #endif
>>>>>
>>>>>
>>>>>
>>>>> The open question is whether we are deprecating the method,
>>>>> or just alert users/developers that this method carries with
>>>>> it some performance penalties...
>>>>>
>>>>>
>>>>> I don't know the answer to this question...
>>>>>
>>>>>
>>>>>
>>>>>    Luis
>>>>>
>>>>>
>>>>>
>>>>> --------------------
>>>>> Hauke Heibel wrote:
>>>>>>
>>>>>> Hi Luis and Tom,
>>>>>>
>>>>>> How about deprecated warnings? I have a small sample which worked with gcc
>>>>>> 3.4.4, VS cl.exe 14.00 and Intel C++ compiler 9.1. I admit that there might
>>>>>> be problems with other compilers since I am not sure if that declspec
>>>>>> belongs to the standard. I saw that there also exists a deprecated attribute
>>>>>> (http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Function-Attributes.html#Function%20Attributes).
>>>>>>
>>>>>> Regards,
>>>>>> Hauke
>>>>>>
>>>>>> Here is the sample:
>>>>>> ----------------------------
>>>>>> class Foo
>>>>>> {
>>>>>> public:
>>>>>>  __declspec(deprecated) void GetDeformationFieldRawPointer(){}
>>>>>> };
>>>>>>
>>>>>> int main(int argc, char*argv[])
>>>>>> {
>>>>>>  Foo f;
>>>>>>  f.GetDeformationFieldRawPointer();
>>>>>>  return 0;
>>>>>> }
>>>>>> ----------------------------
>>>>>>
>>>>>> Tom Vercauteren wrote:
>>>>>>
>>>>>>> Hi Luis,
>>>>>>>
>>>>>>> Thanks for the changes!
>>>>>>>
>>>>>>> As far as encouraging people to use the raw pointer function, I don't
>>>>>>> see a better solution than documenting it as you did.
>>>>>>>
>>>>>>> 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
>>>
>>
>