I can appreciate that many of you find this sort of code reorganization to be quite attractive, and will concede that it might at some point minimize errors. However, it is perhaps worth pointing out that when an Inkscape binary built from current trunk was run today under valgrind, and given the trivial task of opening an SVG file consisting of just 5 lines of text, rotating them a little, and then quitting without saving, the resulting log file contained 34432 "lost in" records and 6 "uninitialized" records.
In brief, Inkscape at present seems to be exceedingly sloppy in how it handles memory, and I would rate the squishing of the vast majority of these memory issues as a far higher priority than the reorganization of the code. Unfortunately finding these is not going to be trivial since many of them show up in messages like this one:
==2926== 12 bytes in 1 blocks are possibly lost in loss record 10,043 of 54,283 ==2926== at 0x402B9B4: operator new(unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==2926== by 0x8111EB0: Geom::Path::Path(Geom::Point) (path.h:183) ==2926== by 0x3FE851E3: ???
How one would fix these I have no idea, since "???" is not terribly informative, and the memory locations are likely to vary from run to run (and certainly from link to link.) The string "???" appears 91134 times in the valgrind log file.
This is all pretty ironic since eliminating exactly these sorts of memory issues was one of the reasons C++ was created in the first place. Yet here we have an example of C++ code with far more memory issues than I have ever encountered in any C project, and unfortunately with the majority (I think) of them of the type indicated above, making them exceedingly hard to find. Now it may well be that many of these are not actually memory issues per se, but are instances where g++/Inkscape's memory handling confuses valgrind. Even that would be a problem though, because the extra "noise" makes it hard to find the real memory issues.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech