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

tom fogal tfogal at sci.utah.edu
Mon Jan 24 16:11:42 EST 2011


"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());

> 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.

-tom



More information about the vtk-developers mailing list