> I would label your third point as a subcategory of the second, as it is impossible to have a garbage collector without having some sort of overhead. It's imp

> I would label your third point as a subcategory of the second, as it is impossible to have a garbage collector without having some sort of overhead. It's impossible to have a heap allocator without overhead. How much overhead you have depends on the design constraints and the trade offs. Particularly if you are dealing with more sophisticated constraints like memory fragmentation and other issues, a GC might actually be an easier and lower overhead way of solving the problem. More importantly, you missed the most important aspect of the second point: "you do not pay _for what you do not use_". You and copx would be surprised to know that pretty much since the standard committee started working on it, garbage collection has been something on the table for C++, but they've never been able to get a proposal that everyone was happy with. I also think that the "No GC" category is perhaps not the right name. What C++ was really about was making UDT's first class types and therefore supporting value semantics. A side effect of that is that GC isn't nearly the priority it might otherwise be.