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

[Jean-Christophe Fillion-Robin]

Great works Marcus

Being a heavy user of VTK, Qt and CTK ... vtkScopedPointer usage is
consistent with what's done in Qt world.

It's concise and user/developer friendly ... it give a clear idea of what
the goal is. The reference count will be decreased if the object get out of
scope ...

Jc

On Mon, Jan 24, 2011 at 4:21 PM, Marcus D. Hanwell <
marcus.hanwell at kitware.com> wrote:

> 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:
> >> >
> >> > =A0
> http://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
> _______________________________________________
> 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
>
>


-- 
Phone: 1-518-836-2174
Ext: 304
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20110124/3821dcf7/attachment.html>