[vtk-developers] Plan to make CMake 3.3 and C++11 required

[Marcus D. Hanwell]

On Tue, Jan 17, 2017 at 12:15 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> On Tue, Jan 17, 2017 at 10:04 AM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
>>
>> On Tue, Jan 17, 2017 at 11:52 AM, David Gobbi <david.gobbi at gmail.com>
>> wrote:
>> > There's definitely a place for std::unique_ptr in VTK, however.  There's
>> > lots of code that does local allocation with new/delete that could be
>> > cleaned up.
>>
>> Although vtkNew fills that role quite well too, and can be used with
>> the other VTK smart pointers quite easily. For those that wanted to
>> use unique_ptr it would be good to make that easy for them, but I
>> wonder if tweaks to vtkNew would be preferable unless we make
>> vtkObject derived classes behave more like normal C++ classes, i.e.
>> removing implicit reference counting, allowing use of new/delete
>> operators, managing memory using STL smart pointers.
>
>
> I wasn't even considering std::unique_ptr for VTK objects.  I was
> more thinking of local allocation of memory for arrays and POD
> objects or legacy methods that return an alloc'd "char *" that needs
> to be deleted.
>
That makes more sense, and yes it would be great although some could
be replaced with std::string, std::vector and other C++ containers.
>
>> > I believe that the main thing holding us back from more widespread use
>> > of
>> > smart pointers is our rule for using forward declarations in VTK
>> > headers,
>> > rather than including other headers.   And it's a rule that I don't want
>> > to
>> > see changed.
>> >
>> I thought it was also the design of the vtkObject base class, and the
>> implicit reference counting. Unless we make very significant changes
>> to the vtkObject hierarchy/design it would seem like a terrible idea
>> to pay for implicit reference counting and for C++11 smart pointers.
>> The use of the object factory mechanism forcing the use of the static
>> New() also adds some overhead.
>
>
> Here I meant that, if it wasn't for our "no unnecessary header rule",
> we could use vtkSmartPointer to declare VTK class members and
> hence avoid calling ->Delete() in the destructors.  I was using the
> term "smart pointer" in the broader sense, i.e. I was including the
> current vtkSmartPointer in the definition.  Apologies for the confusion.
>
That is already the case, and I have modernized some classes. You can
use vtkNew and vtkSmartPointer in class declarations, and we went to
some effort to ensure they could be forward declared. Not to keep
linking to it, but
https://blog.kitware.com/a-tour-of-vtk-pointer-classes/ has an example
of this being used in a class header with forward declared classes. I
tested it before writing the article, and routinely use vtkNew and
vtkSmartPointer in that context.