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

[Andrew Maclean]

David,
   It's a good point, initially I was surprised to see std::auto_ptr appear
in VTK code.

However on reflection I think that programmers (especially the younger
ones) will naturally gravitate towards using std::unique_ptr and
std::shared_ptr for the simple reason of code robustness, since, in these
cases, the compiler does all the memory management and object tracking etc.

So younger programmers or those who have only used C++11 and later
compilers will naturally use these functions, which is a good thing.

We need to attract these programmers and provide a mechanism whereby the
paradigms that they are familiar with can be accommodated.

Regards
   Andrew

Andrew Maclean
On 20 Jun 2016 8:24 pm, "David Cole" <DLRdave at aol.com> wrote:

> Since auto_ptr is only used in 4 files, wouldn't it be easier to simply
> eliminate its use? Why add CMake logic and complexity for such little
> benefit? Why the sledgehammer when a tiny little jeweler's screwdriver will
> do?
>
>
> David C.
>
>
> On Monday, June 20, 2016, Andrew Maclean <andrew.amaclean at gmail.com>
> wrote:
>
>> 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/eadbc063/attachment-0001.html>