[Paraview-developers] Question about deep and shallow copy

[Cornelis Bockemühl]

Dear all,

More and more self-learning about the beauty of programming the "filter
logic" of ParaView/VTK, and very well aware of what "deep" and "shallow"
copying means in general I just want to make sure I am doing the right
thing. It is about avoiding both stupid and hard to debug memory leaks, or
else unnecessary redundancy of data in memory.

I am sorry that this is now getting a bit long, with quite a number of
"verification questions", all about memory management in VTK. So if there
is somewhere some kind of tutorial article available on that subject:
please point me to that one and I will happily do my homework and read it
myself!

Let me explain a filter that I am currently writing. It takes data from a
CSV file and converts it into some geometry stored as a
vtkUnstructuredGrid. These are the steps I am doing:

1. read the CSV file using the vtkDelimitedTextReader that gives me a
vtkTable.

Now I am having a local smart pointer to a vtkDelimitedTextReader object
that owns the data that are contained in the vtkTable. In other words: If I
do nothing else, the vtkTable data will be removed from memory together
with the reader object - right?

2. create a local vtkPoints and a vtkUnstructuredGrid object (both using
smart pointers again) and build up the geometry by reading the vtkTable.

After this, the vtkTable could be safely removed (not needed any more), and
I assume that the smart pointer to the reader (see 1.) will take care of
that - right?

At the same time I am now having the unstructured grid that is internally
linked also with the points. If nothing else happens, both would be safely
removed from memory when leaving the function - right?

3. create another local object of class vtkCleanUnstructuredGrid (again
smart pointer) that "cleans" the initial grid. Nothing special regarding
memory handling: everything is still in memory anyway so far.

4. finally copy the resulting grid into the output vtkUnstructuredGrid.
This one is not any more local and represents the final result of all the
efforts.

Intuitively I would have done this copying with a "DeepCopy" - assuming
that I would otherwise leave the output grid with invalid pointers to
memory objects that have gone (because they were local).

However, I have seen example code of other filters where in such a
situation a "ShallowCopy" was done.

If the latter really works it would mean that internally all the data
structures are relying on managed pointers (vtkSmartPointer or similar).
Honestly I was not really able to figure out by reading the source code
whether this is the case or not...

But if this would be the case, I could do both a shallow or a deep copy -
and it would work at least, neither creating dangling pointers nor dead
data storage. Only the shallow copy would of course be much more efficient.

Is the latter conclusion right?

In more general terms I had the impression that actually at least the
"abstract data array" (vtkAbstractArray) that seem to be the base of all
other more specific arrays are somehow managed.

Meaning: I can have some data structure containing 5 vtkAbstractArray
objects (like a table, or whatever), do a "shallow" copy to the output data
object and add 2 more vtkAbstractArrays: this would not interfere with the
integrity of the input data.

However, if I would do the same, but then not add more arrays but e.g. more
elements to the "shallow copied" arrays: then I would indeed create some
unwanted "back propagation" of my changes into the input data object.

Is this again the correct reasoning?

Which would basically mean: arrays can be assumed to be "managed" somehow,
while single data items are not.

Again: Maybe all these things are somewhere summarized a bit, so I can just
read it myself!??

Actually "deep copy" is always possible - just in order to play safe -, but
I want to "shallow copy" as much as possible, but of course without
interfering with the filter input data or generating dangling pointers!

Thanks a lot for any helpful hints!

Regards,
Cornelis

-- 
Cornelis Bockemühl
Basel, Schweiz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20161221/aca223f8/attachment.html>