2 ) We do not necessearily want to delete the "shadow"-data (should be refactored later!) when the object is deallocated. If it was moved to the constructor, the PTrie implementation would break. It sometimes just "moves" data to a new object - this is an optimization to remove uneeded memory-allocation; removes practically seven of eigth needed calls to malloc.
The behavior can be observed in lines 366-391 of PData.h, lines 373 and 390 are interesting. The code handles moving a bucket (or parts thereof). Note that "EncodingStructure" objects are allocated in a consecutive array, and cannot be reused.
5 ) Constructor never used, removed. The following constructer is similar; it does not cause memory-leak, it is the desired behavior to copy enough data to recreate the marking. Added comments in code explaning the issue.
2 ) We do not necessearily want to delete the "shadow"-data (should be refactored later!) when the object is deallocated. If it was moved to the constructor, the PTrie implementation would break. It sometimes just "moves" data to a new object - this is an optimization to remove uneeded memory-allocation; removes practically seven of eigth needed calls to malloc.
The behavior can be observed in lines 366-391 of PData.h, lines 373 and 390 are interesting. The code handles moving a bucket (or parts thereof). Note that "EncodingStructure" objects are allocated in a consecutive array, and cannot be reused.
5 ) Constructor never used, removed. The following constructer is similar; it does not cause memory-leak, it is the desired behavior to copy enough data to recreate the marking. Added comments in code explaning the issue.
Empty files are removed, fix-branch is lp:~verifydtapn-contributers/verifydtapn/Cleanup.