[vtk-developers] RFC: vtkScopedPointer - a new hope?

[David Gobbi]

On Mon, Jan 24, 2011 at 2:07 PM, David Cole <david.cole at kitware.com> wrote:
> On Mon, Jan 24, 2011 at 4:06 PM, David Cole <david.cole at kitware.com> wrote:
>> On Mon, Jan 24, 2011 at 3:48 PM, Marcus D. Hanwell
>> <marcus.hanwell at kitware.com> wrote:
>>> On Mon, Jan 24, 2011 at 3:41 PM, tom fogal <tfogal at sci.utah.edu> wrote:
>>>> "Marcus D. Hanwell" <marcus.hanwell at kitware.com> writes:
>>>>> Some of you may remember my dreams of a concise way of initializing
>>>>> VTK objects, that would go out of scope and be destroyed at the
>>>>> appropriate time. Inspired by the Qt scoped pointer, [. . .]
>>>>>
>>>>> http://review.source.kitware.com/759
>>>>
>>>> scoped (and other) smart pointers were introduced with tr1, back in
>>>> 2003 IIRC.  Further boost has had this for quite some time:
>>>>
>>>>  http://www.boost.org/doc/libs/1_45_0/libs/smart_ptr/scoped_ptr.htm?sess=94fbb4fa5cfd2b2071c3be193acb355d
>>>>
>>>> I realize that vtk is a bit stuck because it has already shipped some
>>>> smart pointers, and thus probably must continue to do so for some time
>>>> due to backward compat requirements, but I'd discourage *extending*
>>>> the trend.  This is a painful interop problem, especially with larger
>>>> software systems -- there's probably some C++ platitude that states,
>>>> "Every library eventually evolves a smart pointer implementation."
>>>>
>>>> Or there is now, at least.
>>>>
>>> Would any of these scoped pointers actually work with VTK derived
>>> objects? We have private constructors, need to call the static New
>>> method, and the Delete method on destruction. I also don't see VTK
>>> depending on TR1 features, or Boost for quite some time. The class is
>>> quite minimal, and I think it would complement the other two pointer
>>> classes that help to manage VTK derived objects.
>>>
>>> Marcus
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>>
>> The boost discussion points out an important consideration here,
>> though: the name "scoped pointer" is assumed to be non-copyable and
>> non-transferrable out of the scoped context in the boost world. Here,
>> with your implementation, and with a reference counted system like
>> vtkObject, the ownership *can* be transferred outside the context of
>> the scoped pointer variable itself.
>>
>> So.... by using the same name as boost for something that is slightly
>> different, (but still extremely useful within VTK), we may be adding
>> to the heap of confusion that is smart/auto/scoped pointer discussions
>> in the C++ world.
>>
>> Might we be able to come up with a better name for it that does not
>> already have a different shade of meaning in the context of a "very
>> large" and "familiar to many" project like boost?
>>
>
> It's really just a vtkSmartPointer with an "easy create" syntax... Isn't it?
>
> Maybe vtkEasyPointer would be a better name?

I like ScopedPointer better than EasyPointer.  But I liked the old
name vtkNew even more, because it made it obvious that an object was
being created.  How about another suggestion:

vtkAutoPointer<vtkSomething> a;

The name "auto" gives a sense that an object is being allocated.  It
implies "this creates an automatically garbage-collected object",
while the name vtkScopedPointer makes it sound like a pointer is being
created but not an object.

Just my 2 cents.  The name vtkScopedPointer is not that bad.

 - David