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

[Luis Ibanez]

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