[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