<div dir="ltr">Dear all,<div><br></div><div>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.</div><div><br></div><div>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!</div><div><br></div><div>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:</div><div><br></div><div>1. read the CSV file using the vtkDelimitedTextReader that gives me a vtkTable.</div><div><br></div><div>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?</div><div><br></div><div>2. create a local vtkPoints and a vtkUnstructuredGrid object (both using smart pointers again) and build up the geometry by reading the vtkTable.</div><div><br></div><div>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?</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>However, I have seen example code of other filters where in such a situation a "ShallowCopy" was done.</div><div><br></div><div>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...</div><div><br></div><div>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.</div><div><br></div><div>Is the latter conclusion right?</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Is this again the correct reasoning?<br clear="all"><div><br></div><div>Which would basically mean: arrays can be assumed to be "managed" somehow, while single data items are not.</div><div><br></div><div>Again: Maybe all these things are somewhere summarized a bit, so I can just read it myself!??</div><div><br></div><div>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!</div><div><br></div><div>Thanks a lot for any helpful hints!</div><div><br></div><div>Regards,</div><div>Cornelis</div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Cornelis Bockemühl<br>Basel, Schweiz<br></div>
</div></div>