{}.Get());
}
```
So basically, the implicit cast only works when the `vtkNew` object is not a temporary rvalue that would be destroyed at the end of the statement. If someone really wants to get the pointer out of the temporary, they can use `Get()`, but that’s a “here be dragons” operation and requiring the extra call prevents mistakes.
---
### Author:  [@allison.vacanti](https://discourse.vtk.org/u/allison.vacanti)
#### Post date: [March 16, 2019, 8:08pm UTC](https://discourse.vtk.org/t/vtknew-and-vtksmartpointer/469/14 "2019-03-16T20:08:53Z")
The merge request is here if anyone wants to take a look: [https://gitlab.kitware.com/vtk/vtk/merge\_requests/5308](https://gitlab.kitware.com/vtk/vtk/merge_requests/5308)
---
### Author:  [@amaclean](https://discourse.vtk.org/u/amaclean)
#### Post date: [March 16, 2019, 11:21pm UTC](https://discourse.vtk.org/t/vtknew-and-vtksmartpointer/469/15 "2019-03-16T23:21:34Z")
Looks nice, when the dust settles, it would be nice to have an article and guidelines as to the use of vtkNew/vtkSmartPointer/vtkWeakPointer since this is now a bit dated: [A Tour of VTK Pointer Classes](https://blog.kitware.com/a-tour-of-vtk-pointer-classes/) also I attempted to introduce a section in the [VTK TextBook](https://lorensen.github.io/VTKExamples/site/VTKBookLaTeX/VTKTextBook/), section: **3.11.2 VTK Pointer Classes**. The original text book was written well before smart pointers so I rewrote most of the code in the PDF version of the textbook to mainly use vtkNew, sometimes vtkWeakPointer (e.g. Fig 3-25) reserving vtkSmartPointer for uses like in std::vector.
---
### Author:  [@amaclean](https://discourse.vtk.org/u/amaclean)
#### Post date: [March 16, 2019, 11:24pm UTC](https://discourse.vtk.org/t/vtknew-and-vtksmartpointer/469/16 "2019-03-16T23:24:09Z")
> [@allison.vacanti](#):
>
> IMO they’re both still useful to have because of convention – `vtkNew` means “I own this pointer, which must remain the same for my lifetime”, `vtkSmartPointer` means “I use this pointer, which came from somewhere else and might change,” which is useful to know at a glance when maintaining code.
I like this comment, this is what I mean about clarifying the roles of vtkNew and vtkSmartPointer.
---
### Author:  [@allison.vacanti](https://discourse.vtk.org/u/allison.vacanti)
#### Post date: [March 17, 2019, 12:21am UTC](https://discourse.vtk.org/t/vtknew-and-vtksmartpointer/469/17 "2019-03-17T00:21:27Z")
Agreed. Updating the docs / textbook and making a new “Best Practices” blog post is definitely in order as we iron out the remaining issues.
---
### Author:  [@dgobbi](https://discourse.vtk.org/u/dgobbi)
#### Post date: [March 18, 2019, 1:44am UTC](https://discourse.vtk.org/t/vtknew-and-vtksmartpointer/469/18 "2019-03-18T01:44:05Z")
> [@allison.vacanti](#):
>
> I’d avoid using this pattern in public APIs until we know that the python support for `vtkNew` can handle it.
Python support for vtkNew is absent right now, but it would be easy to add. The wrappers just have to capture the returned vtkNew object, Get() the pointer, construct a Python object, and then let the vtkNew go out of scope. This would require around 20 new lines of code at most.
---
### Author:  [@will.schroeder](https://discourse.vtk.org/u/will.schroeder)
#### Post date: [March 19, 2019, 6:40pm UTC](https://discourse.vtk.org/t/vtknew-and-vtksmartpointer/469/19 "2019-03-19T18:40:17Z")
Nice discussion and work.
Are there any concrete plans to work through the code base and make everything consistent / uniform ? We seem to be good at identifying solutions but often they are only partially implemented 🙂 which can lead to frustrated users (and developers for that matter).
---
### Author:  [@allison.vacanti](https://discourse.vtk.org/u/allison.vacanti)
#### Post date: [March 19, 2019, 7:13pm UTC](https://discourse.vtk.org/t/vtknew-and-vtksmartpointer/469/20 "2019-03-19T19:13:13Z")
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?](https://discourse.vtk.org/t/vtksmartpointer-and-vtknew-in-vtks-api-best-practices/518):
>
> 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_ptr`s 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.
[Next page](https://discourse.vtk.org/t/vtknew-and-vtksmartpointer/469.md?page=2)