"Unfortunately, you can't tell the class of a C++ object given a pointer to it at run time....which is why you can't automatically collect the garbage of C++ pr

"Unfortunately, you can't tell the class of a C++ object given a pointer to it at run time....which is why you can't automatically collect the garbage of C++ programs." That's a somewhat self-serving use of ellipses. Here's the actual text: "Unfortunately, you can't tell the class of a C++ object given a pointer to it at run time. So if you debug a crashed C++ program and find a pointer somewhere in its guts, and you don't know its type, you'll have to guess that "0000000600000005" is a Point. Which is completely obvious, because that's the way a pair of adjacent integers looks like in hexadecimal memory listings of a little endian 32 bit machine. And two adjacent integers might be a Point. Or some other two-integer structure. Or a part of a three-integer-and-a-float structure. Or they might be two unrelated numbers which just happen to be adjacent. Which is why you can't automatically collect the garbage of C++ programs." Which part are you claiming is wrong? (Be careful.) The entire first paragraph even Bjarne Stroustrup would agree with once he was done hemming and hawing. Post-mortem inference of types of dynamic objects in C++ programs is undecidable. In higher-level OO languages, memory is organized as framed objects, not as a bag of bytes. The main thrust of this questioned answer had nothing to do with GC. And he's right about this being what makes GC and C++ bad fits for one another, too, though he skipped a few steps. Getting out the sock puppets, without the ability to tell the type of an in-memory object, you can't compact the heap. If you want to move an object, you can't just assume anything in memory with the bit pattern of that object's address is a pointer, because it might be two shorts or a double or whatever that happens to have that bit pattern. While conservative, non-compacting garbage collectors can be built in theory, they're too slow in practice. Check out the source to Hans Boehm's C/C++ collector; it stops all the threads in the process, and analyzes liveness starting from each thread's CPU registers, each thread's entire stack, and the entire static data segment. By the implementors' own admission, this will not scale to large numbers of threads, or large address spaces. Even if this approach is refined significantly, if your garbage-collected program lives long enough, you need compacting garbage collection, or fragmentation will kill you just as surely as exhaustion would have. And if you are so convinced that performant, general purpose GC can be dropped into large C++ codebases, you have a straightforward way of both shutting me up, and having a very interesting ycombinator startup. A drop-in operator new overload that does compacting, generational, safe GC would have a readymade market, with very deep pockets, from companies stuck maintaining enormous piles of C++ code with intractable memory management bugs.