Surviving C++
c0de517e.blogspot.com
c0de517e.blogspot.com
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.
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.
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.
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'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.
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!
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.
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. :)
C is a very simple and elegant language. You can write down the specs for it on a dinner napkin. And implement a compiler for it overnight.
C++, on the other hand? A fully compliant compiler for it took over a decade.
C's struct "tag name space".
Trigraphs and \ line splicing.
Replace #include with symbolic import.
Noticing this and rushing to C++'s defense has become a popular thing to do lately. I wonder why.
Myself, I merely have one comment: Bjarne Stroustrup has been known to criticize 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.
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.
Style points for C++ have been rehashed endlessly. "C++ Coding Standards" is pretty good IIRC: http://www.amazon.com/Coding-Standards-Rules-Guidelines-Prac...
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.
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.
No. Just don't.
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.
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.