vtkNew and vtkSmartPointer

[allison.vacanti]

The current implementation of vtkNew and vtkSmartPointer is already complete. By “making everything consistent / uniform”, do you mean making smart pointers replace raw pointers everywhere? If so, I’ve started another discussion to go over the specific issue of using smart pointers in VTK’s API:

vtkSmartPointer and vtkNew in VTK's API. Best practices?

As best practices emerge in a post-C++11 world, one of the newer guidelines becoming commonplace is “don’t use raw pointers.” Preferring smart pointers prevents a host of mistakes and provides an additional level of safety and robustness over explicit memory (or refcount) management. Obviously this doesn’t fit much of VTK’s historical usage, but there are a few ways we can help make it easier to use VTK from projects with more modern coding practices. The vtkNew, vtkSmartPointer, and vtkWeakPoi…

In a perfect world, it’d be good to start using smart pointers in our APIs. But realistically, I don’t see that happening as it would break virtual APIs and/or introduce hidden overload issues for projects that extend VTK’s classes. If we wanted to do that, we might as well rewrite VTK from the ground up and use internal shared_ptrs to manage object lifetimes, like VTK-m does.

With that effort vs. benefit ratio, I more or less expect the end result to be “leave things as they are”, but wanted to start the discussion, gauge interest, and see what possible solutions the community comes up with.