Hacker News Reader

Comment by spoiler | Hacker News Reader

I've recently started working in C++ (I've had some prior knowledge, but mostly basics) and whenever I try to Google stuff up, a few of the results are Don't use C++ because of X

I read a few of them out of curiosity, and realised that they are mostly religious reasons to hate C++, hardly any of them are proper, factual, or empirical reasons. So, my hypothesis is the following: They were unable to learn C++, and because of immaturity, decided it was stupid[0][1].

[0]: I'm no saint to this. I said on numerous occasions Erlang is shit because I couldn't wrap my head around the syntax.

[1]: I believe it's a phenomenon associated with Psychological Projection, but I might've confused it with something else.

View on HN

C++ isn't the easiest language to work with, but what I find truly bizarre are all the internet people who apparently hate C++ while also praising C as wonderful and "elegant". I'm convinced that the vast majority of them have never written anything significant in C, which is a painful experience tolerated only by systems programmers who actually need something that's one step above a portable assembly language.

C++ only fails if you try to write it like C, and don't take advantage of all the lovely new tools it gives you. It's always been a more useful language for nontrivial projects, and C++11 elevates it so much further.

Yes, many fail to understand that most C++ warts are caused by its C compatibility and are actually C issues.

Which incidentally also affect Objective-C for the same reasons.

Dear HN,

Is it really necessary to start another language war thread?

Sincerely, a happy C developer.

I am not starting a another language war.

Just stating the fact that when someone posts "C++ is horrible because of X", that X is either also available in "ANSI C", caused by compatibility with C semantics or compatibility with C toolchain.

How about this one: "C++ is horrible because of implicit copy constructors"? That one's not in C :-).

The newest additions to C++ for functional programming and automatic typing are quite intriguing. Blaming everything wrong with C++ on C is as disingenuous as labeling everything about C++ as wrong because one thing about it is wrong.

> How about this one: "C++ is horrible because of implicit copy constructors"? That one's not in C :-).

I also mentioned compatibility with C semantics.

"The Design and Evolution of C++" contains lots of such examples.

C doesn't implicitly convert one struct into another. Why implicitly convert one class into another just because I created a constructor in one class that takes the other class as a parameter? The "explicit" keyword should have been "implicit", with the default behavior reversed.

I agree. I think Stoustrup got many things right, particularly RAII. It's not a consistent language, but its a very practical one.

I'm a 20 year C programmer finally making the transition to C++ and as far as I can tell the main advantages C has left are: * Faster compilation * Comprehensible error messages * No cout

I have more issue with the poor performance of iostreams than with the interface, personally. Typesafe and type deducting string formatting is a pretty nice thing to have.

Maybe because iostreams are synchronized with stdio by default? It's possible to disable that for a big speed boost.

There's also the issue that iostreams might be implemented on top of stdio for simplicity. Hard to make it faster in that case!

Even then, it's pretty much the only place in the stdlib that extensively uses virtual calls, via std::locale. It's very complicated implementation-wise (I was actually working on an implementation of it once and it's not fun at all) and hard to find places to optimize it.

It's not that it's too heavy for a console app's output, really, but for things like converting numbers to strings and vice-versa (a-la boost::format) it is definitely a lot slower than atoi/sprintf.

I use C++ daily at work.

C++ code tends also to have a lot of allocations and data copying going on. I know you can get around those, but it seems like C++ programmers don't.

C++ looks nicer at first sight, but when you want to make sure error handling is correct, there's practically little advantage compared to C. Sure, C++ does have STL, but programmers still seem to occasionally allocate function stack and return a pointer to it and manage to do buffer overflows.

C has much simpler flow of execution. C++ exceptions mean there are eventually a lot of different possible code execution paths. In C, flow of execution is almost always simple and predictable.

C++ invites style where logic is spread over many layers of abstraction. It's often hard to see the whole picture of what's going on because of that. Instead you have to check all those constructors, destructors, watch out for inheritance, etc. In C, most related logic tends to be in same source file.

A lot of bugs I've seen in legacy code are related to these issues.

Most Internet hivemind (euphemistically called "conventional wisdom") behavior is more about belonging and less about discussing truth. It's similar to the rants about Perl's ugliness: it's up to the programmer to make it readable.

C++ can be a perilous language, but it affords a surprising amount of expressive power with a very low performance overhead. It requires you to be focused and think clearly about things like object lifetimes. It rewards thinking hard ahead of time to simply jumping in, writing code, and debugging it until it works.

I have seen people giving up on C++ without actually even trying to learn it.

Somehow all these pointers are "scary" and "hard". And people are usually trying to learn C++ the wrong way. (Lets download this big library/framework and figure out by doing)

There are good arguments against C++, but they resume to its extreme complexity and lack of extra safety compared to C. Both are fair points and why I avoid it.

What do you mean by "Lack of extra safety compared to C"? I'd have imagined the exact opposite, but maybe I'm missing something there.

C++ is way safer than C thanks to stronger type checking and what you can achieve via library types like STL collections.

However the C unsafety is still present due to the compatibility compromises with C in C++'s design.

With teams it is very hard to control what each developer makes use of, even with static analysis.

That was kind of my point. I really think that if anything, C++ cannot be as unsafe as C. You can do crap in C++ just as well as you can do in C, but at least C++ gives you tools to do things way more safely IMO.

Yes, that is one reason why I never liked C, but do enjoy C++ for personal projects or when everyone on the team is quite comfortable with it.

For the other type of enterprise projects I rather use languages that follow Algol linage of memory safety.

I consider modern C++ to be a lot safer than C. Between RAII, copy, and move schematics the pointer use has gone down quite a bit.

When you do use pointers, we finally have a real null pointer literal now. (I believe the latest C spec has also received this.)

C++ is certainly crufty. The language has been around for a long time and many features in the specification exist to support legacy code. This is a side effect of being a living language with a huge user base.

Modern C++ tends to be fairly clean and reasonably easy to work in. Herb Sutter has some great talks and blog articles around the topic. For example: http://channel9.msdn.com/Events/Build/2014/2-661

I think it is somewhat telling that even gcc switched to C++.

Reply on news.ycombinator.com