[vtk-developers] Plan to make CMake 3.3 and C++11 required

David Gobbi david.gobbi at gmail.com
Tue Jan 17 12:15:17 EST 2017

On Tue, Jan 17, 2017 at 10:04 AM, Marcus D. Hanwell <
marcus.hanwell at kitware.com> wrote:

> On Tue, Jan 17, 2017 at 11:52 AM, David Gobbi <david.gobbi at gmail.com>
> wrote:
> > There's definitely a place for std::unique_ptr in VTK, however.  There's
> > lots of code that does local allocation with new/delete that could be
> > cleaned up.
> Although vtkNew fills that role quite well too, and can be used with
> the other VTK smart pointers quite easily. For those that wanted to
> use unique_ptr it would be good to make that easy for them, but I
> wonder if tweaks to vtkNew would be preferable unless we make
> vtkObject derived classes behave more like normal C++ classes, i.e.
> removing implicit reference counting, allowing use of new/delete
> operators, managing memory using STL smart pointers.

I wasn't even considering std::unique_ptr for VTK objects.  I was
more thinking of local allocation of memory for arrays and POD
objects or legacy methods that return an alloc'd "char *" that needs
to be deleted.

> I believe that the main thing holding us back from more widespread use of
> > smart pointers is our rule for using forward declarations in VTK headers,
> > rather than including other headers.   And it's a rule that I don't want
> to
> > see changed.
> >
> I thought it was also the design of the vtkObject base class, and the
> implicit reference counting. Unless we make very significant changes
> to the vtkObject hierarchy/design it would seem like a terrible idea
> to pay for implicit reference counting and for C++11 smart pointers.
> The use of the object factory mechanism forcing the use of the static
> New() also adds some overhead.

Here I meant that, if it wasn't for our "no unnecessary header rule",
we could use vtkSmartPointer to declare VTK class members and
hence avoid calling ->Delete() in the destructors.  I was using the
term "smart pointer" in the broader sense, i.e. I was including the
current vtkSmartPointer in the definition.  Apologies for the confusion.

 - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170117/a6537220/attachment.html>

More information about the vtk-developers mailing list