[vtkusers] Understanding vtkSmartPointers

Fcs ftpronk at engits.com
Mon May 28 11:45:51 EDT 2018


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


More information about the vtkusers mailing list