::New();
quad->SetPoints(std::move(points));
//points shoud be null, but it still can be used
double normal[3] = {0, 0, 0};
double point1[3] = {points->GetPoint(0)[0], points->GetPoint(0)[1], points->GetPoint(0)[2]};
double point2[3] = {points->GetPoint(1)[0], points->GetPoint(1)[1], points->GetPoint(1)[2]};
double point3[3] = {points->GetPoint(2)[0], points->GetPoint(2)[1], points->GetPoint(2)[2]};
```
---
### Author:  [@Paulo\_Carvalho](https://discourse.vtk.org/u/Paulo_Carvalho)
#### Post date: [March 9, 2020, 10:59am UTC](https://discourse.vtk.org/t/does-vtksmartpointer-support-std-move/2771/2 "2020-03-09T10:59:08Z")
Issue #1: objects handled by `vtkSmartPointer` are managed by VTK framework so you don’t need to do memory management yourself (`move`-ing included).
Issue #2: `std::move(points)` is moving the `vtkSmartPointer` object, not the `vtkPoints` object it refers to. `vtkSmartPointer` objects are small objects, so there is no point in `move`-ing them
Issue #3: if you `move` an object, you don’t try to access it after the move. I’m surprised that your program didn’t crash.
---
### Author:  [@AllisonVacanti](https://discourse.vtk.org/u/AllisonVacanti)
#### Post date: [March 12, 2020, 3:49pm UTC](https://discourse.vtk.org/t/does-vtksmartpointer-support-std-move/2771/3 "2020-03-12T15:49:58Z")
`vtkSmartPointer` recently learned some things about C++11, but it was shortly after the `8.2.0` release:
[https://gitlab.kitware.com/vtk/vtk/-/commit/30605cd78d9a36f67dbf7c0c9d54e879d908ce8c](https://gitlab.kitware.com/vtk/vtk/-/commit/30605cd78d9a36f67dbf7c0c9d54e879d908ce8c)
After the next release, `std::move` on `vtkNew`, `vtkSmartPointer`, and `vtkWeakPointer` should work as expected. For `vtkSmartPointer` in particular, moving will move the pointer into the destination, clear the source, and not touch the reference counter.
To clarify some points:
> [@](#):
>
> Issue #1: objects handled by `vtkSmartPointer` are managed by VTK framework so you don’t need to do memory management yourself ( `move` -ing included).
>
> Issue #2: `std::move(points)` is moving the `vtkSmartPointer` object, not the `vtkPoints` object it refers to. `vtkSmartPointer` objects are small objects, so there is no point in `move` -ing them
This is not true. Though `vtkSmartPointer`s are small, there is a large cost in copying them – making a copy of a smart pointer increases the pointee’s reference count, which involves a ton of virtual calls, atomic operations, and possibly some list traversals. It’s a very heavy operation that does more than just copy some bits.
> [@](#):
>
> Issue #3: if you `move` an object, you don’t try to access it after the move. I’m surprised that your program didn’t crash.
The original question is asking _why_ the code _doesn’t_ crash, and the usage was just an example of this issue. After the next release, the moved-from pointer will be null and the code will crash (as expected).
---
### Author:  [@lassoan](https://discourse.vtk.org/u/lassoan)
#### Post date: [March 12, 2020, 8:46pm UTC](https://discourse.vtk.org/t/does-vtksmartpointer-support-std-move/2771/4 "2020-03-12T20:46:33Z")
> [@AllisonVacanti](#):
>
> Though `vtkSmartPointer` s are small, there is a large cost in copying them – making a copy of a smart pointer increases the pointee’s reference count, which involves a ton of virtual calls, atomic operations, and possibly some list traversals.
Yes, `vtkSmartPointer<>::operator=` is much slower than a pointer copy, but it is still extremely fast: vtkSmartPointer copy takes 300ns, while a regular pointer copy takes 2ns (in debug mode; in release mode, vtkSmartPointer copy takes 45ns, while the simple pointer copy test was removed by compiler optimization; measured by copying then setting a pointer to nullptr 1 million times).
Making std::move release reference in the old pointer is the right thing to do, but performance improvement is expected to be negligible (unless you copy millions of VTK object pointers per second).
---
### Author:  [@AllisonVacanti](https://discourse.vtk.org/u/AllisonVacanti)
#### Post date: [March 13, 2020, 11:22pm UTC](https://discourse.vtk.org/t/does-vtksmartpointer-support-std-move/2771/5 "2020-03-13T23:22:54Z")
Sure, if performance isn’t important, it isn’t important 🙂
But consider that (assuming a 3GHz processor clock), that 45ns overhead just wasted 150 cycles to _copy a pointer_ – and that’s a best case scenario microbenchmark with a warmed up L1 and the branch prediction preconfigured to zip through all of the virtual calls. Throw in a few mispredicted branches and cache misses, and that adds some serious overhead!
For some of the situations where VTK is used, such as stereoscopic VR, where you have to render a scene 120x/second to hit a comfortable 60 fps – that leaves 8ms per render. ~100ns for a pointer copy starts to hurt pretty bad.
It depends on how performance sensitive the application is, for sure, but move semantics are important considerations when using `vtkSmartPointer`s – I wouldn’t discount them so readily 🙂