[vtk-developers] Smart pointer declaration macro?

[Jeff Baumes]

Ok, time to summarize. The votes are laid out as follows:

On SurveyMonkey:

1. 12
2. 4
3. 1
4. 6

Via email:

1. 4 (Bill, Karthik, Wes, Aashish)
2. 2 (Jeff, David D)
3. 1 (David C)
4. 3 (Stephane, Marcus, David G)

Either way you slice it, the status quo has won this vote. There were
at least 3 or 4 more suggestions made that weren't part of the poll,
so we shouldn't necessarily consider the issue dead. As a result of
the discussion, I for one will at least try to stop using macros for
smart pointers, since people seem to agree that macros should be
avoided.

Perhaps individual ideas, like Brad's suggestion, should be discussed
on different threads as they come up. This thread has gotten too
unwieldy.

Jeff

On Thu, Jan 28, 2010 at 12:25 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> This is reply mainly to Brad about vtkLocalPointer<vtkClass>.
>
> I'm not quite sure why having a smart pointer declaration do a
> allocation is such a bad thing, as long as it is explicit that an
> object is being allocated.  How about if we make the allocation
> explicit in the name of the template, e.g.
>
> 4. vtkNew<vtkClass> object;
>
> I know that it appears that the object is being created on the stack,
> but that shouldn't be an issue because the stl container classes use
> heap allocation, too.
>
>   David
>
>
> On Thu, Jan 28, 2010 at 9:49 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> I always break the smartpointer line.
>>  vtkSmartPointer<vtkImageRectilinearWipe> wipe =
>>    vtkSmartPointer<vtkImageRectilinearWipe>::New();
>>  wipe->SetInput(0,pad1->GetOutput());
>>  wipe->SetInput(1,pad2->GetOutput());
>>  wipe->SetPosition(100,256);
>>  wipe->SetWipe(wipeMode);
>>
>> I think it looks OK and does not take up much room.
>>
>> On Thu, Jan 28, 2010 at 11:41 AM, Francois Bertel
>> <francois.bertel at kitware.com> wrote:
>>> I'm strongly opposed changing the max line length.
>>>
>>> I often have two or three xemacs windows open at the time to compare
>>> different source files or source file versions and increasing the line
>>> length will make it harder. This is the useful also with other source
>>> file comparison mode, like vimdiff. It also enforce developers to be
>>> succinct. I can probably find ten other reasons to keep the limit that
>>> way.
>>>
>>> On Thu, Jan 28, 2010 at 11:32 AM, Sean McBride <sean at rogue-research.com> wrote:
>>>> On 1/28/10 10:09 AM, David Cole said:
>>>>
>>>>>The fact that we disallow abbreviations by convention means that we will end
>>>>>up with long names. It would be better to leave things as they are and
>>>>>everybody get over the "waa waa this name is too long" syndrome.
>>>>
>>>> Another thought, which I'm not necessary advocating, but thought should
>>>> be mentioned: increase max line length from 80 to something higher.  80
>>>> chars is what my Apple II maxed out at, it seems a bit low for today's
>>>> monitors.
>>>>
>>>>
>>>> On 1/28/10 10:32 AM, David E DeMarle said:
>>>>
>>>>>Do any of the above options allow intellisense and similar code
>>>>>completion tools to expose the pointed to class's method/members?
>>>>
>>>> Similarly, would any of the proposed forms make identifying leaks by
>>>> line number harder?  Would valgrind any similar tools still be able to
>>>> identify a leak as being on line 123?
>>>>
>>>> --
>>>> ____________________________________________________________
>>>> Sean McBride, B. Eng                 sean at rogue-research.com
>>>> Rogue Research                        www.rogue-research.com
>>>> Mac Software Developer              Montréal, Québec, Canada
>>>>
>>>>
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> François Bertel, PhD  | Kitware Inc. Suite 204
>>> 1 (518) 371 3971 x113 | 28 Corporate Drive
>>>                      | Clifton Park NY 12065, USA
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>
>>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>
>>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>



-- 
Jeff Baumes, Ph.D.
R&D Engineer, Kitware Inc.
(518) 881-4932
jeff.baumes at kitware.com