"...Otherwise, the class has to have some data associated with it. Are we sure we want to link Foo both to the interface of Bar and to its in memory layout?
No, you are not. Don't do it, use composition instead. [More Effective C++, 33 Make non-leaf classes abstract]"
Sigh. Dude either didn't read the book, or didn't think about what it's saying; he's just quoting the chapter headings and drawing a silly conclusion. Abstract classes can most definitely have data in them, and Meyers is not saying that you should restrict yourself to object composition (he has a whole section on how and when to use inheritance in the first book!)
The point Meyers was making is that if you're allowed to instantiate a base class that implements an assignment operator, you can easily get into a place where you can do bad, mixed-type assignments. If you make your base classes abstract, you can prevent this problem -- hence the chapter title.
This isn't the only bit of bad advice in this blog post -- just one that I picked out at random. It's another example of a rant by someone who knows just enough about C++ to be dangerous, but not enough to be insightful. Flagged.
This is the issue with C++. This level of knowledge of any other language you'd be fine to let the guy do some code. You have to have considerably better developers.
With C++ you have this huge dearth of people who know enough about the language to convince someone else of it, then you get them on your project and they blow stuff up by doing it subtly wrong.
C++ has uses, but it's the sulfuric acid of programming languages: you have to have good personnel control and fire those who screw around outside the boundaries of the right style. A programming group with one guy programming like C with classes and another guy programming like it's Ocaml without garbage collection, and you're in for a mighty piece of hell.
"This level of knowledge of any other language you'd be fine to let the guy do some code. You have to have considerably better developers."
Don't tell that to every Ruby and Python startup that's hiring "rock star" developers. You might hurt their feelings.
At the end of the day, you want the best programmers you can afford on any project, so I don't think it's a particularly compelling argument to say that Blub is a better language because it lets less-qualified people get work done faster.
That said, this guy gives the impression of being competent at C++, but most of his advice is really quite bad. It's fairly easy to write and informed-sounding rant about Python or Ruby, too. The difference is that more people in this forum know those languages, so they're more willing to call bullshit on the poseurs. The level of C++ (and C) competency in the web world is, frankly, disturbingly low.
>At the end of the day, you want the best programmers you can afford on any project, so I don't think it's a particularly compelling argument to say that Blub is a better language because it lets less-qualified people get work done faster.
That's complete pap. Of COURSE you want less capable people to get things done. That's the entire point of junior and midlevel developers. Less expensive is sometimes (not always) more useful than being super great. You act like only very good dev's with 8-13 year of industry experience are any use at all with that attitude. Some things really shouldn't require geniuses to do.
"You act like only very good dev's with 8-13 year of industry experience are any use at all with that attitude. Some things really shouldn't require geniuses to do."
You're overstating the claim. You don't need to be a "genius" to be productive in C++. Yes, there's a learning curve. It may even be a little steeper than in other languages, but it's entirely possible for a smart new grad to contribute meaningfully to a large C++ project. It happens at Microsoft and Google and thousands of other companies every single year.
This line of argument against C++ is entirely overblown.
I really don't see the point of the tone the article adopts. If it is aimed at C++ users, badly mouthing C++ can only put them off what could be useful advice. If it is aimed at C++ bashers, they don't need the C++ advice anyway.
Bad mouthing of C++ has become a popular thing to do lately. I think it's partly because C++ is a difficult and time consuming language to learn with many caveats, and people find it easier to give up and bash it instead.
Just because C++ doesn't feel as "clean" as other languages doesn't mean it's not incredibly powerful, widely supported, and a fun language to develop in. To all the haters out there - give it a chance!
I did and do a fair share of C++ programming, but I disagree that it is fun to program in C++. Nearly everything is tedious in C++. Just to give one example: you can quickly prototype a class in Python or Ruby and rapidly revise it as your insight with respect to the problem improves. In C++ you have to decide for each member whether it should be an ordinary value, reference, pointer, or smart pointer, which methods to make virtual, behavior for the copy constructor and assignment operator, etc.
Of course, this is a double-edged sword. Higher-level languages have made choices so that you do not have to tinker with such details. But that also prevents you to decide on such behavior when necessary.
C++0x goes a long way in making many aspects of the language more enjoyable, such as type inference, lambda functions, range based loops and defaulted/deleted methods. But once a performant alternative shows up and becomes mainstream (strict Haskell? ;)), I will switch.
C++ has uses, but it's the sulfuric acid of programming languages: you have to have good personnel control and fire those who screw around outside the boundaries of the right style. A programming group with one guy programming like C with classes and another guy programming like it's Ocaml without garbage collection, and you're in for a mighty piece of hell.
But the main reason it's not as clean is because it has had to maintain backwards compatibility with C, which is 40 years old now.
Ironically, had C++ been 'cleaner' and not as backwards compatible with C from the outset, then we probably would not be having this conversation today because no one would have ever adopted it. :)
Really? I haven't seen many people rushing to defend it at all, just a whole lot of "C++ sucks, let's all stick with C".
I should hope Stroustrup has been known to criticize it! It wouldn't be a very good language if it was designed by someone who couldn't spot flaws in his own work. By no means is C++ a perfect language, and everyone knows that. I'm just saying that doesn't make it any less usable or worth learning.
You assume the intersection of the sets of people who use C++ and of people who dislike C++ is empty. I have used C++ for some projects and don't exactly love it. I don't love Java, PHP and Ruby either, but I can use them.
In fact, no one uses straight C++ to make anything, in real world everyone starts by sub-setting C++ into something "safer" and then adding back the fundamental missing features (i.e. memory management, serialization, reflection and so on) via libraries, macros or other trickery (i.e. code to code transformers, code generators or parsers and so on), so really the C++ we use is not a standard, but a studio specific version of the language.
I really don't understand this at all. He seems to be saying that using "straight C++" would mean using the worst parts of the language in the worst ways, but not taking advantage of the features that make C++ usable. If he really thinks everyone uses macros, code generators, or code transformers to do real-world C++, then he's wrong. I've been using C++ professionally for almost ten years now, and I've never seen anything like that except: a few legacy macro tricks that we easily replaced with better, non-macro techniques; and Qt's preprocessor, which we never actually used in production code.
For gaming and embedded software, you will need further rules for performance. I'm not sure why this is a ding on C++. Doesn't any reasonably powerful language have performance pitfalls? Don't use CLOS in your embedded systems, folks.
C++ as a medium for our art looks more like statuary marble than modeling clay: it requires a team of muscular stone cutters under the guidance of a genius in order to produce some amazing sculptures. And once a given idea has been translated into the stone, you hardy can change it without re-sculpting most of it or having to work in the constraints that the shape it currently has impose on you.
This is only true if your system is badly factored or if you are averse to recompiling. "Ahhh, arrgh, no, I refuse to change the interface of this fundamental class referenced by every other object in the system because the next compile-link cycle will take ten minutes! I'll leave it crappy for the rest of eternity just so I don't have to wait ten minutes for a compile, or because my approach to changing this extremely fundamental class is to keep making haphazard changes to its interface until my code finally works, so my ten or twelve compile-link cycles will cumulatively take almost two hours." Fine, we'll have an adult make the change instead.
Now I'm really not suggesting that it doesn't suck when you have to wait ten minutes to recompile your system when you change an interface that every other source file in your system includes, but I hope recompilation time is not the weightiest consideration in that case.
It's not a coincidence that the more a language is dynamic, the less need there is for fancy debugging tools. Who needs a watch window indeed, if I can just add on the fly a widget on screen that graphs the value of a given variable?
This is a legitimate complaint. Building instrumentation into a C++ system is a pain in the ass, and it will never be as powerful as in a language with introspection.
Well, the art of sculpting in C++, the art of design, becomes really the art of subdividing our sculpture in pieces, the real design challenge is all about how to cut or work into pieces. Too many of them and the sculpture will be a fragile and ugly mess (translation: craptastically slow OOP shit). Too little and we loose flexibility.
As far as I can tell, the point here is that if C++ was a better language, bad design wouldn't be a problem. If it took C++ to drive him to consider OO design principles, I'd hate to see the code he wrote in other OO languages. Also, decomposition is not the only consideration. There are cross-cutting concerns such as memory management, logging, and instrumentation.
The design principles at the end of the post are better and more comprehensively covered by "Large-Scale C++ Software Design": http://www.amazon.com/Large-Scale-Software-Design-John-Lakos... Some of the language points in that book reflect the immaturity of C++ implementations when the book was written, but the design guidelines are still relevant.
In general, it's very hard to say anything original about C++. Practitioners and proponents of C++ are much more aware of its limitations than its detractors realize. Also, this may come as a shock to the web generation, but C++ is a topic that is very well covered by available books. Just as you might browse through a few relevant blogs to see if someone else has already made the same point you were about to make, with C++ you should do the same with the highly-regarded books.
> If he really thinks everyone uses macros, code generators, or code transformers...
That's not what he was talking about. He basically said that if you take two different teams, they will most likely use different subsets of C++ features. One will be all about classes, hierarchies and (god forbid) boost and other will be using C++ as beefed up C. That sort of thing.
I'll say this about C++: the worst thing about it is that each new job requires you to learn what is 'good' and what is 'taboo' at the new company. One man's natural and elegant is another man's obtuse and illegible.
Your thoughts are exactly what I have encountered in the last 10 years.
The author of the article really gives me the impression that he should just really stick to ruby and have his lolz.
C++ is a language, it has slowly evolved over 15+ years, it isn't the prettiest thing. Different people use different parts. Deal with it. If you don't want to work with c++ find a job doing something else.
No, you are not. Don't do it, use composition instead. [More Effective C++, 33 Make non-leaf classes abstract]"
Sigh. Dude either didn't read the book, or didn't think about what it's saying; he's just quoting the chapter headings and drawing a silly conclusion. Abstract classes can most definitely have data in them, and Meyers is not saying that you should restrict yourself to object composition (he has a whole section on how and when to use inheritance in the first book!)
The point Meyers was making is that if you're allowed to instantiate a base class that implements an assignment operator, you can easily get into a place where you can do bad, mixed-type assignments. If you make your base classes abstract, you can prevent this problem -- hence the chapter title.
This isn't the only bit of bad advice in this blog post -- just one that I picked out at random. It's another example of a rant by someone who knows just enough about C++ to be dangerous, but not enough to be insightful. Flagged.