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

[Bill Lorensen]

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
>>
>