[vtk-developers] Smart pointer declaration macro?

[David Doria]

On Thu, Jan 28, 2010 at 10:09 AM, David Cole <david.cole at kitware.com> wrote:
> On Thu, Jan 28, 2010 at 9:30 AM, Jeff Baumes <jeff.baumes at kitware.com>
> wrote:
>>
>> On Thu, Jan 28, 2010 at 9:24 AM, Wes Turner <wes.turner at kitware.com>
>> wrote:
>> > I'm not really against the idea, but I am not convinced that this
>> > actually
>> > does anything real for us.  We are just replacing the line:
>> > vtkSmartPointer<vtkClass> myLocal = vtkSmartPointer<vtkClass>::New();
>> > with
>> > vtkSmartPointer<vtkClass> myLocal(true);
>> > I don't mind change and will go along with whatever is decided, but we
>> > are
>> > trading conciseness for clarity.  I generally don't mind multiple line
>> > code,
>> > so shortening the signature is not a big deal to me.  Is there really
>> > consensus that this is needed?
>>
>> I think people will either use this or else some ad hoc macros like
>> the VTK_CREATE macro that's currently scattered around tests/examples.
>> Since I've seen several people use a macro (myself included), I think
>> that shows some sort of consensus that the current length of code
>> required for initializing smart pointers is unacceptable.
>>
>> Jeff
>>
>
>
> This is bad:
> VTK_CREATE(vtkClass, myLocal);
> because it hides the fact that a local variable is being declared, it hides
> the fact that a heap allocation is being made and it makes it hard to step
> using a debugger.
> This is bad:
> vtkSmartPointer<vtkClass> myLocal(true);
>
> because it hides the fact that a heap allocation is being made, and the
> "true" is meaningless to the novice/casual reader.
>
> 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.
> Perhaps since there is no consensus, things should be left alone for now and
> taken up with the ARB for a decree... ("Talk to the ARB!")
>
> David C.
>

The ARB really takes away from the "open source community" idea. Why
defer a valid discussion to an extreme subset of people? What we need
is a better organization and voting system than a mailing list -
that's why the discussions are so hard to follow/analyze.

Let's try this:
http://www.surveymonkey.com/s/8JRNJZV

Thanks,

David