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

[Marcus D. Hanwell]

On Mon, Jan 24, 2011 at 4:11 PM, tom fogal <tfogal at sci.utah.edu> wrote:
> "Marcus D. Hanwell" <marcus.hanwell at kitware.com> writes:
>> 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. =A0Further boost has had this for quite some time:
>> >
>> > =A0http://www.boost.org/doc/libs/1_45_0/libs/smart_ptr/scoped_ptr.htm?ses=
>> s=3D94fbb4fa5cfd2b2071c3be193acb355d
>> >
>> > 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. =A0This 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,
>
> The standard smart pointers accept the pointers; they do not know how
> to allocate them.  So for example:
>
>  std::tr1::shared_ptr<vtkDataset> ds =
>    std::tr1::shared_ptr<vtkDataset>(vtkRectilinearGrid::New());

There is something to be said for nicer API, even at the expense of a
little duplication IMHO.
>
>> and the Delete method on destruction.
>
> Yeah, they accept a function pointer for custom delete implementations
> (the above line would actually fail w/o supplying the custom deleter,
> IIRC).
>
>> 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.
>
> Well, I think that's kind of my point.  As long as these things keep
> getting added, they keep getting used, and the impetus for getting
> a better long term solution is lost.  Furthermore, it makes it more
> difficult to switch over when the appropriate time comes, because now
> backwards compatibility is suddenly an issue.
>
My counterargument would be for concise, specialized API where it
helps. I think this is one of those cases, although perhaps the naming
is the contentious issue. Having to pass in the construction and
custom deleter really makes the initialization even more verbose than
what we have.

As with many toolkits, we do not have the luxury of requiring TR1 or
C++0x anytime soon. Even if we did in my opinion supporting a concise
way of constructing scoped objects is important for code readability.

Marcus