On 21 Kwi, 18:44, "Simonson, Lucanus J" <lucanus.j.simon...@intel.com> wrote:
I prefer to have a graph object that owns all graph nodes and deallocates them all in its destructor than have "liberated" graph nodes that can be assigned between different graphs. Stl style is already providing the big productivity boost that GC claims. Since the graph and geometry data structures are small and many in number it is better (in terms of both space and time) to store them in vectors and copy them around than allocate them dynamically through any mechanism including garbage collection. I don't think GC offers any advantage over my current style of graph or geometry programming in terms of either productivity or performance of the code generated. Cyclical ownership is just bad design. All the objects in the cycle have the same "life" and an object that encapsulates that relationship and can be used to scope them as a unit is the obvious solution, not GC. If the argument for GC is because it makes bad design less bad, then it can't win over the argument for good design.
I never have problems with leaks in my graph or geometry algorithms because I never type new and delete execpt in the rarest of circumstances, and even then the ownership is clear and they are deallocated in the destructor of an object, making the code exception safe. GC solves a problem that does not exist for me. If other people still have this problem they should learn how to apply C++ in a way that doesn't lead to such problems, not rely on GC to let them implement sloppy design. C++ can be as productive to program in as Java if you use it well, and memory pooling with RAII will always outperform GC.
struct User; struct Group { std::vector<User*> users; }; struct User { Group* group; }; Taking into account that the data can be used in multiple modules. Do you know when and where to release the memory for this type of objects? C++ language, enforces restrictions on mapping the structures of databases, because that does not have a Garbage Collector.