[Insight-developers] IRIX64-6.5-CC-n32-Continuous errors and CastImageFilter
Luis Ibanez
luis . ibanez at kitware . com
Tue, 06 Aug 2002 08:47:35 -0400
Hi Aljaz,
The ITK standard was to receive Raw pointers as arguments
to functions/methods and to return SmartPointers from
functions/methods.
The reason for receiving Raw pointers in arguments was
to make polymorphism possible.
After the UNC meeting this year, it was pointed out that
the use of SmartPointers implied a penalty in performance
due to Mutex operations. We went through all the toolkit
and reduce the use of SmartPointers returned from functions.
Currently most of the code receives and returns raw pointers.
The only functions/methods returning SmartPointer are those
constructing the object to be returned.
Luis
=============================================================
Aljaz Noe wrote:
>>
>>True, I didn't notice that. You can, however, avoid the
>>typedef lookup by
>>simply using "const ElementType*" instead of
>>"ElementType::ConstPointer".
>>This is actually preferable as it is ITK standard to pass raw
>>pointers as
>>function arguments instead of smart pointers. In this case it won't
>>change anything since ElementType::ConstPointer isn't a smart pointer
>>anyway.
>>
>
> That's an ITK's standard??? Why didn't anybody tell me this 6 months ago
> when I spent quite some time making the whole FEM code using T::Pointer
> instead T*... Originally everything was written using the T* syntax for
> pointers. And it worked, and it was much simpler, too...
>
>