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

[Tom Vercauteren]

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