What nonsense. Here's what I learned from this link: trolling isn't as effective when it requires the trollee to read 10 pages of text.
This is garbage. Please flag it for collection.
I was reading it as a neutral party, however some very knowledgeable C++ appeared to convince all comers that the FQA is either based on ignorance or is disingenuous.
http://stackoverflow.com/questions/385297/whats-wrong-with-c...
Summarizing: "C++ is hard but makes some things possible that aren't in other languages."
The FQA dude is a troll: he criticizes without offering better alternatives, ignoring tradeoffs and considerations and overlooking any advantages offered by C++.
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.
First, the premise was false: you can tell the type of a pointer to a dynamic object -- you use RTTI. You don't have to "guess" that the object is a Point, because you can use dynamic_cast<>() or typeid() to tell for sure.
Second, the conclusion was false: it is possible to write a garbage collector for C++. You cited a very popular one in your response.
So what do we have? You can tell the type of an object at runtime, and you can write a garbage collector for C++. When both the premise and the conclusion of an argument are incorrect, well...let's just say that it's hard to be less correct than that. It's Not Even Wrong.
As for your defense, let's be clear: you're not suggesting that it's impossible to "automatically collect the garbage of C++ programs" -- you're arguing that it's impossible to do it efficiently. I dispute that argument, too, but it has absolutely nothing to do with the comment that I quoted. It's a straw-man.
The bottom line is that the quoted statement was absurd, and you're only setting up a straw-man (about the efficiency of C++ GCs, and about the ability to drop them into large codebases.) We could perhaps have an interesting discussion about those topics, but our discussion wouldn't make the original article any less of a flame-bait.
This debate is becoming inane. I challenge you to name another language that allows for arbitrary references to blocks of memory, while still guaranteeing that the data type of said references can always be correctly inferred. You're just nit-picking.
That's exactly the point! Allowing arbitrary references to blocks of memory means inferring types is hard! That's exactly what the FQA entry is saying! ... I'm stunned at how adamant you're being about this. Do you really think the author doesn't know about RTTI? Seriously, dude, you're wrong.
Again, you're trying to set up a straw man: the question is not whether or not it's efficient to do type inference in C++ (for the record: it's NOT any more efficient in a dynamic language), the question is whether it's possible at all.
It is possible to do so, the original argument was incorrect, and you're trying to have an entirely different debate.
I would probably use Boost's smart pointers to handle the reference counting though.
Which you can't do. Seriously, when did it become okay to call out a problem with the general case as nonsense because there's a specific case that avoids the issue?