I agree totally with Zed Shaw on this, but some quick observations:<p>* C++ circa 2000 (before mainline g++ could handle Alexandrescuisms) is significantly different from C++ circa 2010, albeit in ways that probably upset Shaw even more (the more central role boost has taken, the more "expressive" templates have gotten, don't call me on any of this stuff).<p>* C++ std::string is an abomination, but you can always just do what I've done and what lots of other C++ programmers whose code I've read have done: just use char* and a simple string library (or a custom string class).<p>* Ditto for stream IO, which is a huge C++ misfeature but which is also pretty much irrelevant (I know of no part of the standard C++ library outside of things that explicitly support stream I/O that rely on you using it).<p>* I don't get the POSIX argument at all; just call the POSIX functions, they work fine. Nobody mandates that you use (say) ACE_wrappers to do systems programming.<p>* const-correctness may be another misfeature (I know I make fun of it), but the point isn't hard to see: if you take the time to const-correct your code, the compiler will spit out errors that would have otherwise been runtime faults.
There appear to be a lot of good rants <i>against</i> C++. To name a few:<p>* Linus Torvalds : <a href="http://lwn.net/Articles/249460/" rel="nofollow">http://lwn.net/Articles/249460/</a><p>* C++ Frequently Questioned Answers : <a href="http://yosefk.com/c++fqa/" rel="nofollow">http://yosefk.com/c++fqa/</a><p>Are there any good passionate <i>pro</i> C++ versus C arguments?
I'm going to keep saying this until I turn blue in the face. Perhaps if I stamp my feet it might get more attention (wink)<p>Please stop confusing the language with the APIs or the available libraries and features of the language.<p>This sounds simple, but it's profound: simply because you <i>can</i> do something, that doesn't mean that you <i>have to</i> do it that way.<p>To use Zed's example, let's say I'm hacking around a lot of strings. What's wrong with rolling a string class, adding a member or two? You only have to carry around a bunch of nonsense if you want to. If you don't want to use templates and strings and such, don't use them.<p>This is another in a long line of articles that go something like this: We did X in this certain way, and boy did it suck. Therefore all of X is the devil's work and will destroy civilization.<p>You can put about anything you want in for X. It's like a (oddly enough) template engine for writing blog entries.<p>You should go through stages in your career, with just about any X. Stage one is that you are ignorant. Stage two is that you've tried it. Stage 3 is expertise. Stage 4 is hate, and Stage 5 is grudging acknowledgement that parts of X are okay for certain situations. You realize that yes, X is done poorly maybe 99% of the time, but lots of smart people worked on it and there are some little gems in there that are useful from time to time.<p>Looks like Zed is stuck on Stage 4<p>Throw away the templates, throw away all the library stuff you don't like -- is there a reason to make a class and wrap some things? If so, you can do that in C++. You can't in C. It's a very simple question, and it has nothing to do with any of the things Shaw is going on about.
I love C++, but I upvoted this because most C vs. C++ rants focus on things that are not actually C++'s biggest problems. This is one of the few C++ rants that actually brings up of legitimate points. They are not reasons that would stop me personally from preferring C++ over C, but they are valid criticisms.<p>P.S. On the subject of format strings vs. cout and the "<<" madness, C++0x's variadic templates will allow a type-safe printf. So hopefully in the future we WILL see C++ move back toward format strings, but without loosing the type safety. It also gives the possibility of instead of having to remember to use %d for ints and %f for floats, we could just use format strings that use {1}, {2}, etc. as format string placeholders, the way C# does. Freeing you from having to specify in the format string what the type is is something C++0x type-safe-printf would allow you to do that you could never do in C.
Call me unlucky, but I've never worked at a company that had a <i>high percentage</i> of programmers (myself probably included) that could write solid C++ using anything more than the absolute basics, i.e. basically a C subset.<p>I'd pretty much agree with Zed's rant, that C++ often isn't worth the bother, <i>unless</i> you have a project that specifically requires C++ features, <i>and</i> you have a development team that can actually write solid C++.<p>Maybe I'll call this Jonathan's axiom, but if your team doesn't have enough experience to write in a Lisp-y (or any other genre such as ML-y) language, you probably shouldn't be messing with C++ either.<p>Not many people that say they can write C++, actually can.
I don't get these rants. Both C and C++ are such barebone languages that you can take or leave pretty much everything but the common syntax. Zed decides C's string functions are not up to scratch, and so uses bstring. Plenty feel the same about std::string, and will use bstring's CBString, Qt's QString, or some other class in their C++ code. Exceptions? Take them or leave them. setjmp/longjmp? Take them or leave them. Templates? Take them or leave them. Macros? Take them or leave them.
I agree with most of what he says but not with his memory management argument. In C++ you could do something like this:<p><pre><code> f() {
LinkedList list;
populate(list);
use(list);
//forget
}
</code></pre>
Freeing the list elements is done in one place only, in the destructor of LinkedList. In C, you have to call some kind of free function in every single place a LinkedList is used. The burden of managing memory is on the user of a library, not on its creator. I don't think this is enough to justify using C++ though.
I really dislike C++ but more to the point I really dislike other people's C++.<p>This is triple compounded when you only have to do C++ occasionally. I've never even got close to the point of looking at something like const *const char & and reading it like it was something normal like others seem to do.
Exceptionally good critique. But there are exceptions: programming for Google's V8 in C++ is a pleasure. I've never seen any interpreter code so clean and easy to extend. Like a breath of fresh air.
What would be better is if C and C++ divorced each other and people realized that they are two separate languages. All of Google's results for C questions end up linking to some "C/C++" forum, which is almost certainly not what I'm looking for. I'm sure the other way 'round is true too.
<i>"If I wanted to fry my brain trying to figure out how to add two numbers with templates I'd go use LISP."</i><p>Probably just a tongue in cheek comment, but I wonder what he meant.
I have to agree with the spirit of the article. In the late 80s and early 90s, much of my work was in C++, and I did some mentoring, wrote a bunch of C++ books, etc.<p>After my C++ <i>period</i>, I did a major project for myself and just used C - like a breath of fresh air after C++<p>In all my years using C++, I think that the only good applications where C++ made sense was in Nintendo and PC game development at Angel Studios and some VR development for Disney and SAIC. Everything else that I did in C++ should have been done in different languages.
The std::string example given by Zed shows that he didn't hack around C++/STL much.<p>There is a whole entry in Exceptional C++ Style (or another Herb's book) that says how much std::string sucks and how you can write an equivalent extremely quickly.<p>Anyway, don't like std::string ? You can use std::vector in place very easily, that's a well known trick (thanks to the guarantee that &v[0] returns a pointer to the data if v is a vector).<p>He talks about references but he seems to ignore the capability of C++ to offer perfect forwarding which enables you to greatly increase performance and memory usage and that's very difficult to mimic in pure C.<p>There's a lot to write about inaccuracies in this post actually, but what the point? People who hate C++ will discard them and people who love it already know it.<p>I tire of reading posts from people who didn't like a language for whatever reason and try to rationalize it.
This is the first time I heard of Grace C++[1]. Looks very useful. I was looking for string that can be used for binary data. Looks like they support that too.<p>[1] <a href="http://grace.openpanel.com/" rel="nofollow">http://grace.openpanel.com/</a>
I like C or C++ for native but use C++ more because I write it with simplicity. Complex C++ like MFC, Windows API, template hell is disgusting and wrongly gave C++ a bad name.<p>C++ OO can be done to really abstract the application but still be very manageable and simple. Also C++ is a game industry cornerstone. I think game code in C is actually harder to consume that game code in C++.
I always see streams brought up as a critique of C++, at least compared to how it is handled by C, and I agree that they are terrible. However, everyone else also agrees that they are terrible, and as an added bonus the C IO functions are still available.<p>C++ brings a lot of heavy-weight machinery to the table but the best part is that you don't have to use it. If you just want to write C but desire templates to reduce the amount of writing you need to do then so be it, write C-with-templates!<p>My big beef with the language is mostly due to the legacy crud it is saddled with in the C preprocessor. Many of the build time issues I find myself suffering with are because of people, for example, including Windows.h a) in the first place and b) not defining WIN32_LEAN_AND_MEAN. Junior (and senior, for that matter!) developers seldom know how to properly structure their code so that their iteration times don't plummet.
The problem with const string& is that the resulting string is not interned - e.g. one copy in memory, which would later allow to save memory, compare by pointer equality (eq), etc.<p>I understand that the language cannot express it, and that's why other languages (such as lua) do it the right way - immutable strings all the way, or at least by default (NSString)
That was rather bogus. Sure, destructors are horribly complex in their interaction with all of the other horribly complex C++ features. But unless I'm reading it wrong, Aughey wasn't suggesting using all those other features.<p>If you have some reasonable self-control, it is quite reasonable to use C++ as a small superset of C.
There are great C++ projects, but the big compile/link times they have are not a small deal. Also the compiled libraries take a lot of space. Examples:<p>Qt, wxWidgets, LLVM, boost<p>Hopefully we have IncrediBuild at work, and we don't have to deal all the time with such huge frameworks.
Just using constructors/destructors and class encapsulation
makes code so much more readable.<p>And most exception problems are solved with RAII. If you're using RAII, then you won't have memory leaks when exceptions arise.
The problem with a lot of these posts on HN is that the audience seems to be rather biased towards low-performance app areas like web, and business apps.<p>Oh noes! I have to handle 10 requests a second!<p>Take a look at the SWENG-gamedev mailing list for some of the performance issues that people face in games and game tools.<p>/pissing-contest<p>Note: obviously this is not an argument <i>against C</i> instead of C++. It's more to forestall the meta-discussion.
The portable subset of C++ were around long before mozilla, webkit or chromium. Anyone can read mozilla's or google's guidelines about which subset of c++ is safe to use.<p>One of the best examples is Informix RDBMS which was acquired by IBM in 2000. And the second best is... JVM. ^_^
"They'd have been better off to just invent a new keyword:
doesnotfuckingchange and stop there."<p>And now I have tea to clean off of my monitor and keyboard.