[vtk-developers] Smart pointer declaration macro?

[David Gobbi]

On Fri, Jan 8, 2010 at 1:38 PM, David Doria <daviddoria+vtk at gmail.com> wrote:
> On Fri, Jan 8, 2010 at 3:33 PM, Karthik Krishnan
> <karthik.krishnan at kitware.com> wrote:
>> Or have these as typdefs and/or factory methods in a VTK class, as is
>> done in ITK (that would be internally handled via macros in the
>> class), so that usage syntax looks like.
>>
>>  vtkPoints::SmartPointer = vtkPoints::SmartNew();
>> or
>>  vtkPoints::SmartPointer instance(1);
>>
>>
>>
>>
>>
>> On Fri, Jan 8, 2010 at 3:26 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>> On Fri, Jan 8, 2010 at 1:15 PM, David Doria <daviddoria+vtk at gmail.com> wrote:
>>>> I've seen the use of something like this:
>>>>
>>>> #define SPNEW(instance, type) \
>>>> vtkSmartPointer<type> instance = vtkSmartPointer<type>::New();
>>>>
>>>> in many of the tests and elsewhere. It seems like a reasonable savings
>>>> of a whole bunch of characters that appears many many times in most
>>>> functions. Could we standardize something like this so it can be used
>>>> universally without having to see this little #define in every file it
>>>> is used in?
>>>>
>>>> Thoughts?
>>>
>>> Doesn't VTK have enough macros already? ;)
>>>
>>> There are other ways to reduce the repetition, without using macros:
>>>
>>> 1) Add a new constructor argument for smart pointers:
>>>
>>> vtkSmartPointer<type> instance(1); // create an smart pointer and
>>> allocate an object at the same time
>>> vtkSmartPointer<type> instance(0); // create a smart pointer with
>>> "null" as the initial pointer
>>>
>>> 2) Add a non-static "New" method for smart pointers:
>>>
>>> vtkSmartPointer<type> instance;
>>> instance.InstantiateNew();
>>>
>>> etc.
>>>
>>>   David
>
>
> Sure, I hate macros :)
>
> So how do we turn these good suggestions into a final conclusion and
> course of action?
>
> My choice/thought after seeing these initial comments is that it would
> be nice if ITK and VTK shared a similar style (the ::SmartPointer).
>
> Bill - there is plenty of mystery even with the additional typing :)
>
> David D.

Actually, I'll give a "+1" to Bill's comment because I do like code to
be as explicit as possible.

  David G