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

[David Cole]

That's fine.

But having auto_ptr as a fallback seems silly to me. It should just be
eliminated, and then if we depend on unique_ptr, we need to support
only platforms and compilers that support it moving forward.


D



On Mon, Jun 20, 2016 at 7:23 AM, Andrew Maclean
<andrew.amaclean at gmail.com> wrote:
> 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
>>>
>>> ___________________________________________