[vtk-developers] std::auto_ptr replacement for modern compilers.

[Andrew Maclean]

Shawn,
   Firstly thank you for a very clear explanation of the difference between
vtkSmartPointer and std::shared_ptr. It is much appreciated.

Regarding std::unique_ptr.

I think that it will be possible to use std::unique_ptr where it is defined
and fall back to std::auto_ptr without too much effort.

Please see the attached zip file for a test scenario.

However we would need a new define which I have called VTK_HAS_UNIQUE_PTR
and
one new macro: CheckCXXTemplatedExpressionCompiles.cmake

To test it yourself, change "std::unique_ptr<int> ptr" in line 49 of the
CMakeLists.txt file to to something that will never compile e.g
"std::Xunique_ptr<int> ptr".
Remember to delete the cache and run CMake again when you do this.

I have only tested this in windows so it may be buggy.

If you think this approach is reasonable, I'll have a go at creating a
topic.

Of course feedback from anyone else would be appreciated.

Regards
   Andrew


On Mon, Jun 20, 2016 at 1:29 AM, Shawn Waldon <shawn.waldon at kitware.com>
wrote:

> Hi Andrew,
>
> We have had a few discussions about this and here is (roughly) where I
> think things stand.  (To the list: feel free to correct/expand this).
> > So I have two questions:
> > 1) How do we handle future proofing in this case? Most importantly, we
> need to keep std::auto_ptr for older compilers but should move to either
> std::unique_ptr and/or possibly std::shared_ptr. Is there a define that we
> can use?
>
> Yes std::unique_ptr is the right replacement, but we should check if the
> compiler/library supports it and fall back to std::auto_ptr.  I don't know
> of a define that could be used to test this, though one could be added.
>
> > Finally:
> > 2) vtkSmartPointer ... how does this fit in? To me it seems this similar
> to std::shared_ptr. Could vtkSmartPointer just be a wrapper around
> std::shared_ptr for new compilers (C++11 and newer)?
>
> This was a long discussion, but the summary is this: vtkSmartPointer
> assumes that the object itself is reference counted internally and will
> delete itself when that count reaches 0.  std::shared_ptr assumes that it
> needs to keep the reference count and delete the object when that reaches
> 0.  These two different takes on reference counting are hard to reconcile
> and there isn't really a way to easily migrate to use std::shared_ptr.  It
> is also uncertain if we want to...
>
> Shawn
>
>
>
>


-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160620/e01aa247/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CheckForUniquePtr.zip
Type: application/zip
Size: 3809 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160620/e01aa247/attachment.zip>