I'm frustrated with myself that I wasn't following Herb Sutter's blog closely enough that I could have taken part in the conversation over this blog post on Garbage Collection.
I like Herb Sutter. He's very smart, he speaks articulately about C++, and his effect on the C++11 standard has been good. Still, I confess, I'm annoyed that he has allowed himself to be co-opted by Microsoft to lend any support to the C++/CLI, C++/CX and C# food chains, which if they never crash and burn don't deserve to do anything better than fizzle. Vendor-specific languages are structurally evil (Apple is guilty here, too) and he's smart enough to have figured that out for himself. But in my calmer moments I'm willing to concede that these are things about which reasonable people can (and do) disagree.
So, let me give you my take on "Garbage Collection Synopsis, and C++".
The post opens with the quote: "OK, GC was invented half a century ago. When it is going to land in the C++ world?"
This question is so rife with assumptions that those should be dealt with before the question itself is even touched with a barge pole (which is about as close as GC should come to C++). These would be:
1. "GC is desirable for any language"
2. "Anything half a century old is well-defined enough that bringing it into any language should be easy"
3. "C++ wants/needs GC" (I'm holding my breath already!).
Right aways, Herb enumerates three kinds of garbage collection, the first of which is all that C++ usually needs. It wasn't available in the early days when good pointer-wrapper classes weren't widely available, but it's there now and that should be the end of the story for most of us.
The annoying part of the rest of the article including most of its comments, was the utter lack of effort made in identifying and highlighting those situations for which that option was insufficient, and why. @sim82 mentioned that phylogenetics regularly has circular-referenced nodes that make ordinary pointer-wrapping insufficient but didn't elaborate why the weak_ptr/shared_ptr pattern wasn't enough to solve the problem, either.
Martin Vejnár made the interesting observation about putting off memory releases until later (due to processing burden) to which another major commenter, David Abrahams, answered some'at about it being hard to do memory allocation without locking the world. And that has me wondering if in our wonderful multi-core world, there wasn't a way to do this by other means. Let me post on that idea soon.
Two other things annoyed me about the article. One was the "run, don't walk, to watch this video on Garbage Collection" in the main article. The video, while erudite and informative about how garbage collection worked, failed to convince me that it was good for anything other than allowing programmers to be more lazy. The additional specious was made that because C# had it, ASP was a better web-app-server environment than anything else out there. The other was in Herb's answer to three questions that got wrapped up in why any feature (including GC) should perhaps not be included in a computer language at all:
a) How likely will the feature be abused more than used well?
b) How often is the feature needed at all?
c) What cost or how viral is the feature? (does it force itself on those who might not want it)
His answers to these questions failed to convince me that GC belonged in C++, although mentioning Booch's comments on multiple inheritance raised an important point. Still, since C++ is so expressive, things that are actually in other languages, for instance named parameters (native in Python, in boost, here) can be brought in without including it in the language. The chap who raised these questions also asked if Herb's support for GC was related to his position with respect to C#, C++/CLR and C++/CX and here alone was something that remotely convinced me there was some need. After admitting his complicity in those projects (while denying the connection to wanting GC in C++), he goes on to say:
Note that for several years now I've been writing and teaching about Effective Concurrency in all the major languages — C++, Java, C#, and C+pthreads – and in the lock-free code section I keep having to add comments about how certain examples are easy/easier in Java and C#, and hand-wave about what it would take to do them in C++. I hate that.
I'd hate that, too -- but it'd be nice if Herb could have pointed to one of the examples he's talking about. I'm still none the wiser. Looking at the ABA problem, the other concrete item he mentions, it looks like the sort of thing that could be solved by a ZooKeeper-style version#-along-with-data paradigm, which shouldn't be hard to implement inside a library either, in a multi-threaded (thanks C++11), no-lock, portable way, never mind the somewhat trivial solution of thin-wrapping ZooKeeper!
But it's too bad that so much noise clouded what could have been an informative discussion. And I admit that if I had jumped in, it's eminently possible that I would have missed, in the moment, the way to ask a follow-on question that would have turned it to more useful ends.
No comments:
Post a Comment