[vtkusers] Understanding vtkSmartPointers

Tue May 29 18:39:32 EDT 2018

Hi Marcus,
   This is a very clear and succinct explanation of the usage of

vtkNew /

vtkSmartPointer /

vtkWeakPointer .
If you have time would it be possible to do a nice C++11 demonstration
example to be added into VTK Examples?
I have a suspicion that this will be an issue arising again and again.

I'll be glad to help.

Personally (like Bill) I have never liked: .GetPointer()/.Get()  in vtkNew
so I haven't used it much. However ... since it implicitly returns the
pointer now, I'll probably use it more.

Rgeards
   Andrew

>
>
> ---------- Forwarded message ----------
> From: "Marcus D. Hanwell" <marcus.hanwell at kitware.com>
> To: Fcs <ftpronk at engits.com>
> Cc: VTK Users <vtkusers at vtk.org>
> Bcc:
> Date: Mon, 28 May 2018 10:12:24 -0400
> Subject: Re: [vtkusers] Understanding vtkSmartPointers
> On Mon, May 28, 2018 at 7:43 AM, Fcs <ftpronk at engits.com> wrote:
>
>> Using VTK for one of our projects, we are encountering some memory leaks
>> which, in time, cripple our system.  So I'm trying to have a better
>> understanding of the  VTK pointers
>> <https://blog.kitware.com/a-tour-of-vtk-pointer-classes/>  .
>>
>> It was my (erroneous..?) belief that the *vtkSmartPointer*s would destroy
>> the object they were holding when getting out of scope.  Carefully reading
>> the kitware blog post linked hereinabove, and playing around with a test
>> code (code sample below), I now understand that it is objects held by
>> *vtkNew* that will be destroyed when out-of-scope, and that
>> *vtkSmartPointer*s, on the contrary, will keep them alive as long as the
>> reference count is non-zero.  Is this correct?
>>
>
> No, that is not correct. The vtkNew class instantiates a vtkObject derived
> instance and will decrement its reference count when it goes out of scope.
> You can still store what was created by vtkNew in a vtkSmartPointer,
> increasing the reference count to two, and keeping that object alive even
> when the containing vtkNew goes out of scope.
>
> In its simplest form, if you don't use other smart pointer classes with it
> then vtkNew acts much like a stack allocated object, where the object
> created is automatically deleted when it goes out of scope. You must
> remember that all vtkObject derived classes are implicitly reference
> counted - it is built into the API. The smart pointer classes just take
> care of incremementing/decrementing the reference count.
>
>>
>> Now, from a practical point of view:  does this mean that I can, in a
>> class,
>> create an entire VTK pipeline with *vtkSmartPointer*s, and only store the
>> latest object in a member variable to keep every object alive (So, in my
>> code below, only bookkeep the object returned by applyFilters())?  And
>> that
>> when I'm finished, I can call ->Delete() on that object to clean-up the
>> entire pipeline?  Is this a good practice?  Until now, I was painstakingly
>> storing every object created for the lifetime of a pipeline, and I would
>> like to know if I can simplify my code..
>>
>> In my opinion you should aim to never call Delete, but to have a smart
> pointer contain the things needed. I think all pipeline API will increase
> the reference count, and so you only usually need to keep a reference to
> the pipeline objects you are going to keep around/use. The debug leaks code
> will help you verify you got it right.
>
> I would add that we have found in bigger applications that a passing debug
> leaks is not always enough, ensuring objects are deleted when they are done
> with is more difficult but necessary, especially in graphical applications
> that might run for some time. My honest summary of using the smart pointers
> (in classes, local code, etc) is:
>
> 
> vtkNew - when you will instantiate the object, and want to keep a strong
> reference (you can't change what instance a vtkNew variable points to)
>
> 
> vtkSmartPointer - when you might create, or use an instance passed in, and
> ensure it stays around for when you want to make calls. Assigning a
> different instance to one will decrement the one it points to before
> switching it to point to the new instance and incrementing.
>
> 
> vtkWeakPointer - when you want to call API if something is still around,
> check for nullptr before using, will not affect reference count.
>
> I think I wrote something similar back then. Whenever I see code like
>
> vtkSmartPointer<vtkRenderer> renderer =
> vtkSmartPointer<vtkRenderer>::New();
>
> I want to replace it with
>
> vtkNew<vtkRenderer> renderer;
>
> It does the exact same thing with no repetition, and is clearer. The
> examples require backwards compatibility with older VTK, and I don't think
> Bill liked calling .GetPointer()/.Get() on the vtkNew object. You no longer
> have to do that, but it is a more recent addition to the vtkNew API - it
> will implicitly return the pointer to the contained object as
> vtkSmartPointer does.
>
> Hopefully this makes things a little clearer. At the end of the day all
> vtkObject derived classes (read most of the vtk* classes) are implicitly
> reference counted, the choice of vtkNew/vtkSmartPointer should be made
> depending upon how those instances will be used in your code - both will
> decrement the reference count by one when they go out of scope.
>
> Marcus
>
>
>
> ---------- Forwarded message ----------
> From: David Thompson <david.thompson at kitware.com>
> To: "Marcus D. Hanwell" <marcus.hanwell at kitware.com>
> Cc: Fcs <ftpronk at engits.com>, VTK Users <vtkusers at vtk.org>
> Bcc:
> Date: Mon, 28 May 2018 10:30:06 -0400
> Subject: Re: [vtkusers] Understanding vtkSmartPointers
> > ...
> > I think I wrote something similar back then. Whenever I see code like
> >
> > vtkSmartPointer<vtkRenderer> renderer =
> vtkSmartPointer<vtkRenderer>::New();
> >
> > I want to replace it with
> >
> > vtkNew<vtkRenderer> renderer;
>
> With c++11, you can also say
>
>   auto renderer = vtkSmartPointer<vtkRenderer>::New();
>
> which cleans up the smart-pointer case a little bit.
>
>         David
>
>
>
> ---------- Forwarded message ----------
> From: "Marcus D. Hanwell" <marcus.hanwell at kitware.com>
> To: David Thompson <david.thompson at kitware.com>
> Cc: Fcs <ftpronk at engits.com>, VTK Users <vtkusers at vtk.org>
> Bcc:
> Date: Mon, 28 May 2018 10:50:35 -0400
> Subject: Re: [vtkusers] Understanding vtkSmartPointers
> On Mon, May 28, 2018 at 10:30 AM, David Thompson <
> david.thompson at kitware.com> wrote:
>
>> > ...
>> > I think I wrote something similar back then. Whenever I see code like
>> >
>> > vtkSmartPointer<vtkRenderer> renderer =
>> vtkSmartPointer<vtkRenderer>::New();
>> >
>> > I want to replace it with
>> >
>> > vtkNew<vtkRenderer> renderer;
>>
>> With c++11, you can also say
>>
>>   auto renderer = vtkSmartPointer<vtkRenderer>::New();
>>
>> which cleans up the smart-pointer case a little bit.
>>
>> For sure, although in the case of class member variables it doesn't help,
> and I would argue vtkNew is cleaner (and vtkNew still uses far fewer
> characters, you got to preserve the finite resources on disk :P ).
>
>
>
> ---------- Forwarded message ----------
> From: Fcs <ftpronk at engits.com>
> To: vtkusers at vtk.org
> Cc:
> Bcc:
> Date: Mon, 28 May 2018 08:45:51 -0700 (MST)
> Subject: Re: [vtkusers] Understanding vtkSmartPointers
> Dear Mathieu, Marcus and David, thank you for your replies and tips, with a
> special thank to Marcus for his extensive explanations which really
> clarified a few of the subtleties of the VTK pointers.
>
> Marcus, I had few extra questions linked to your reply.
>
>
> > I In my opinion you should aim to never call Delete, but to have a smart
> > pointer contain the things needed.
>
> Is there any danger in calling Delete()? The case I had in mind was to
> perhaps free the memory occupied by a big structured/unstructured grid
> object which would need to live until a sub-grid is extracted from it.
>
>
> > I think all pipeline API will increase
> > the reference count, and so you only usually need to keep a reference to
> > the pipeline objects you are going to keep around/use. The debug leaks
> > code
> > will help you verify you got it right.
>
> How good is the guarantee that this will work? "I think" and "usually" seem
> to imply that my mileage might vary on this one.. :-)  Does it mean that
> this should work in general, but that perhaps some exotic or slightly buggy
> newer features might not behave correctly? The use case I'm trying to
> implement has a variable number of pre-definied filters which I'm chaining
> together. If I test all the possible combinations, and they work, do I have
> the guarantee they will always work?
>
>
> > I would add that we have found in bigger applications that a passing
> debug
> > leaks is not always enough, ensuring objects are deleted when they are
> > done with is more difficult but necessary, especially in graphical
> > applications that might run for some time.
>
> Does this not imply that every vtkObject created should be stored and
> deleted manually afterwards? Or are there other ways to detect living
> vtkObjects when you don't have a direct member variable pointing to it?
> (say, like the vtkPlane created in applyFilters() in my example code..)
>
>
> > It does the exact same thing with no repetition, and is clearer. The
> > examples require backwards compatibility with older VTK, and I don't
> think
> > Bill liked calling .GetPointer()/.Get() on the vtkNew object. You no
> > longer have to do that, but it is a more recent addition to the vtkNew
> API
> > - it will implicitly return the pointer to the contained object as
> > vtkSmartPointer does.
>
> Good to know! Starting from which version is the call to
> .GetPointer()/.Get() no longer needed? We are developing in vtk 6 at the
> moment, but we should update to a new version at some point in the near
> future.
>
> Kind regards,
>
> Francois.
>
>
>
>
>
>
> --
> Sent from: http://vtk.1045678.n5.nabble.com/VTK-Users-f1224199.html
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Search the list archives at: http://markmail.org/search/?q=vtkusers
>
> Follow this link to subscribe/unsubscribe:
> https://vtk.org/mailman/listinfo/vtkusers
>

-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/vtkusers/attachments/20180530/78c2e59e/attachment.html>