### Author:  [@boelraty](https://discourse.vtk.org/u/boelraty)
#### Post date: [February 16, 2021, 7:29am UTC](https://discourse.vtk.org/t/use-std-unique-ptr-with-vtkobject-instead-of-vtksmartpointer/5195/4 "2021-02-16T07:29:18Z")
Thanks for the answers.
I have the same reaction. Why? The rational is to say that the std::unique\_ptr interface is known by everyone, which is not the case of vtkSmartPointer. And some std functions like std::move are not yet available in VTK before version 9.
@ben.boeckel regarding the destructor, this is the purpose of re-implementing default-delete function of std::unique\_ptr. You will be able to call the VTK “Delete()” function which is public.
@lassoan I don’t think it simplifies the VTK syntax in the case of vtkNew. In the case of vtkSmartPointer, you don’t have to call TakeReference. But the win is very limited.
Thanks.
Best.
---
### Author:  [@olesenm](https://discourse.vtk.org/u/olesenm)
#### Post date: [February 16, 2021, 8:48am UTC](https://discourse.vtk.org/t/use-std-unique-ptr-with-vtkobject-instead-of-vtksmartpointer/5195/5 "2021-02-16T08:48:46Z")
I have also struggled a bit using vtkSmartPointer as a localized unique\_ptr. It help a bit if it were move assignable, and had a simple method to clear its reference. Ideally would like one (or both) of these:
```auto
vtkSmartPointer localObject(...);
// sometime later
localObject.reset(nullptr);
// Or
localObject = nullptr;
```
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [February 16, 2021, 1:03pm UTC](https://discourse.vtk.org/t/use-std-unique-ptr-with-vtkobject-instead-of-vtksmartpointer/5195/6 "2021-02-16T13:03:13Z")
> [@boelraty](#):
>
> regarding the destructor, this is the purpose of re-implementing default-delete function of std::unique\_ptr. You will be able to call the VTK “Delete()” function which is public
Is that something that can be done in one place for all VTK objects, needs to be done for each type in its header, or on each declaration of a `std::unique_ptr`. I’ll also note that `std::make_unique` isn’t going to work either due to the `::New()` construction convention.
Getting move semantics into VTK objects would be welcome, but I don’t think it’s going to be easy or gain as much as one might like since VTK likes slinging pointers rather than values around. It would at least help with these wrapper types though.
---
### Author:  [@boelraty](https://discourse.vtk.org/u/boelraty)
#### Post date: [February 16, 2021, 1:33pm UTC](https://discourse.vtk.org/t/use-std-unique-ptr-with-vtkobject-instead-of-vtksmartpointer/5195/7 "2021-02-16T13:33:03Z")
Thanks @ben.boeckel,
The implementation the team did is based on a macro you call for each type you want to use std::unique\_ptr. That means you have to include the header file where you have the macro. The macro is used to re-implement the default-delete function.
I think trying to go outside of the classic usage of VTK object is dangerous since we are not controlling everything happening in VTK.
Best
---
### Author:  [@lassoan](https://discourse.vtk.org/u/lassoan)
#### Post date: [February 16, 2021, 2:47pm UTC](https://discourse.vtk.org/t/use-std-unique-ptr-with-vtkobject-instead-of-vtksmartpointer/5195/8 "2021-02-16T14:47:20Z")
vtkNew already has move semantics - see [vtkNew and vtkSmartPointer](https://discourse.vtk.org/t/vtknew-and-vtksmartpointer/469/9), so you don’t get simplified syntax with std::unique\_ptr.
I understand that developers don’t want to learn new things if it is not necessary. However, in this case the slightly different syntax is used for a good reason: to clearly differentiate objects that use internal reference counting. Trying to cover this up to ease the burden on developers seems to be a step in the wrong direction, as developers may make wrong decisions if they are not aware how things actually work.
---
### Author:  [@cory.quammen](https://discourse.vtk.org/u/cory.quammen)
#### Post date: [February 16, 2021, 2:48pm UTC](https://discourse.vtk.org/t/use-std-unique-ptr-with-vtkobject-instead-of-vtksmartpointer/5195/9 "2021-02-16T14:48:15Z")
> [@olesenm](#):
>
> ```auto
> // Or
> localObject = nullptr;
>
> ```
This is already a valid way to clear a `vtkSmartPointer`’s reference.
---
### Author:  [@olesenm](https://discourse.vtk.org/u/olesenm)
#### Post date: [February 16, 2021, 3:04pm UTC](https://discourse.vtk.org/t/use-std-unique-ptr-with-vtkobject-instead-of-vtksmartpointer/5195/10 "2021-02-16T15:04:04Z")
> [@cory.quammen](#):
>
> ```auto
> // Or
> localObject = nullptr;
>
> ```
>
> This is already a valid way to clear a `vtkSmartPointer`’s reference.
Excellent - it looked like the signature that would be triggered by nullptr would be this:
```auto
template
vtkSmartPointer& operator=(U* r)
```
and I gave up partly down the rabbit hole of `vtkSmartPointer::CheckTypes`. Don’t really see how the `std::nullptr_t` gets promoted to the correct type so instead it appears that the implicit constructor from a raw pointer might instead be involved and that _that_ is assigned in the operator=.
---
### Author:  [@Paulo\_Carvalho](https://discourse.vtk.org/u/Paulo_Carvalho)
#### Post date: [February 16, 2021, 8:26pm UTC](https://discourse.vtk.org/t/use-std-unique-ptr-with-vtkobject-instead-of-vtksmartpointer/5195/11 "2021-02-16T20:26:50Z")
Here’s my two cents: I tend to use each API’s smart pointer. If it’s name is verborragic so be it. Better have a Java-like code than wasting time with mysterious bugs and crashes later. The APIs have different designs and manage their objects differently. I use STL smart pointers only with objects of my classes.
---
### Author:  [@psandana](https://discourse.vtk.org/u/psandana)
#### Post date: [February 17, 2021, 9:45pm UTC](https://discourse.vtk.org/t/use-std-unique-ptr-with-vtkobject-instead-of-vtksmartpointer/5195/12 "2021-02-17T21:45:18Z")
In my opinion, as VTK user, is that vtkSmartPointer is alike std::shared\_ptr rather than std::unique\_ptr.
vtkSmartPointer has a lot of capabilities out of the box, like being compatible with code expecting raw pointers.
It is also good to reflect that vtkObjects follow a pattern without calling c’tors/d’tors directly, so there is no side effects. The same API is shared among defunct TCL, Python and Java.
Despite I tend to prefer standard things, on this case the benefits outlast this preference.