[vtk-developers] Smart pointer declaration macro?

Bill Lorensen bill.lorensen at gmail.com
Fri Jan 8 18:31:37 EST 2010


I'm not all that anti-macro. As Ken stated there is precedence in vtk
to use VTK_CREATE. That's not the name I would have picked, but since
it has been in fairly wide use for some time, I'm OK with it. If that
is the consensus, then the macro should be placed inj a common place
rather than defined everywhere it's used.

-1 on my +1 makes it a 0.

Bill

On Fri, Jan 8, 2010 at 4:46 PM, David Cole <david.cole at kitware.com> wrote:
> On Fri, Jan 8, 2010 at 4:08 PM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
>
>>
>> <snip>
>
>
>>
>> I would like to add my -1, I think needing to split lines in order to
>> declare
>> a new local variable is a little much. I came from a C++ background where
>> any
>> object could be declared on the stack though. For things like the examples
>> it
>> seems to hurt readability to me.
>>
>> Pointer:
>> vtkFloatArray *myTable = vtkFloatArray::New();
>> myTable->Delete();
>> myTable = NULL;
>>
>> Smart pointer:
>> vtkSmartPointer<vtkFloatArray> myTable =
>>     vtkSmartPointer<vtkFloatArray>::New();
>>
>> Smart pointer with macro:
>> VTK_CREATE(vtkFloatArray, myTable);
>>
>> Stack:
>> vtkFloatArray myTable;
>>
>> I would prefer to be able to use something like the first or the last. In
>> classes etc it is often a different story. It seems like there should be
>> some
>> macro or template function to generate variables with less repetition.
>>
>
> Prefer the first and last as much as you want, but we simply can't use them
> in VTK. The first leads to memory leaks because people forget the Delete
> calls. The last cannot be done with vtkObject derived classes because of the
> nature of vtkObject reference counting...
> So we have to pick one of the middle ones...
> It's unfortunate that we've had two +1's and two -1's... that leaves us at 0
> for the moment. I guess that and the fact that it's Friday makes it fairly
> easy to put off a decision until at least next week. ;-)
> *If* we do go with a macro-based approach, I think we can all agree there
> should be one centralized macro that does this and it should be used
> *everywhere* that vtkSmartPointer::New is presently used.
>
> David C.
>
> _______________________________________________
> 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
>
>
>



More information about the vtk-developers mailing list