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

[David Cole]

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
> <javascript:_e(%7B%7D,'cvml','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/f98d4876/attachment.html>