[vtk-developers] Smart pointer declaration macro?
David Cole
david.cole at kitware.com
Thu Jan 28 10:09:47 EST 2010
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20100128/21f26d3d/attachment.html>
More information about the vtk-developers
mailing list