Live data from Hacker News

Why C++ is vastly superior to C

warp.povusers.org

61–70 of 123 posts

Re: Why C++ is vastly superior to C

#61
post #51

Earlier quoted context omitted.

The author of the OP has a pretty well written rebuttal to everything Torvalds has said about C++: http://warp.povusers.org/OpenLetters/ResponseToTorvalds.html

That article is not very informative, and spends a lot of time characterizing Linus as someone with the “C-hacker syndrome.”

I find the article to be vastly more informative than most of Linus' posts about C++, which usually read more like rants than well informed criticism. He does not characterize Linus as a "C-hacker", Linus does that himself by posting an opinion about C++ that completely lacks substance.

Re: Why C++ is vastly superior to C

#62
post #49

Earlier quoted context omitted.

Are you really saying that the time and energy you save coding and debugging by using high level features aren't worth a few minutes of compile time? It won't even be a few minutes except for the first time because of separate compilation.

That is exactly what I'm saying. Compilation of C++ is really surprisingly slow. Mostly because compilation of modern C++ code involves parsing tens of megabytes of headers that mostly use complex to analyze constructs. Fact that C++'s grammar and semantics are incredibly complex does not help fast compilation either. Separate compilation does not solve it much, because many simple changes, that affects only one file…

> Compilation of C++ is really surprisingly slow.

There's definitely something to what you're saying here. Or, rather, maybe something a few years ago. However, I don't think it really applies so much in 2011. Computers have gotten big and fast to the point where this argument is pretty meaningless.

Personally, I stopped caring about compilation time when I got a 3.6GHz i7 with eight in-flight threads. I'm OK with feeding the beast on this one--what I get from C++ is defnitely worth it. (Debugging isn't particularly difficult, I find - you end up using a subset of C++, but there's no way in hell you could implement my subset of C++ in C and not hate working with it.)

Re: Why C++ is vastly superior to C

#63
post #43

Earlier quoted context omitted.

Implicit conversions come to mind. They don't need to interact with anything to be confusing. Consider this program: #include using std::cout; using std::endl; struct C { int x; C(int _x) : x(_x) {} operator bool() const { return 0 != x; } }; struct D { float f; D(float _f) : f(_f) {} operator bool() const { return 0.0f != f; } }; int main() { C c(9); D d(2.0f); if (c == d) { cout g++ 3.4.4 doesn't so much as warn th…

Maybe it's just coming from a dynamic language, but it appears that you've overridden the bool operators to always return true. (except when you pass in 0 and 0.0) If you redefine how two structs of different kinds are compared, who is the compiler to say it's a problem?

In most dynamic languages 0 is false and anything else is true but it normally wouldn't use that information to coerce two values of different types to booleans before comparing them.

Re: Why C++ is vastly superior to C

#64
post #13

Earlier quoted context omitted.

Great job measuring initialization time, now how about showing real world performance differences in actual large programs.

That's compilation time, not initialization time. Compiling C++ is tremendously slow compared to compiling C programs of equivalent complexity, and is a real issue even on modern hardware.

[deleted]

Re: Why C++ is vastly superior to C

#65
post #49

Earlier quoted context omitted.

Are you really saying that the time and energy you save coding and debugging by using high level features aren't worth a few minutes of compile time? It won't even be a few minutes except for the first time because of separate compilation.

That is exactly what I'm saying. Compilation of C++ is really surprisingly slow. Mostly because compilation of modern C++ code involves parsing tens of megabytes of headers that mostly use complex to analyze constructs. Fact that C++'s grammar and semantics are incredibly complex does not help fast compilation either. Separate compilation does not solve it much, because many simple changes, that affects only one file…

Generally, people on Linux will be compiling using Makefiles, so just use make -j to speed it up.

Re: Why C++ is vastly superior to C

#67
post #31

"A few of lines of C++ code would need hundreds, if not even thousands of lines of C code, but an experienced C programmer is used to that." Yea right. This guy is full of it. This article is very biased...

Of course it's biased. It's also not really wrong on a lot of counts. You really can write more expressive, terser code in C++, that sacrifices no readability and only a very tiny bit of performance (on non-embedded platforms). Seriously--RAII alone saves approximately twelve hojillion lines of code (and saves you from hideous factory-pattern libraries spread hither and yon, which is also a plus).

The flip side of that coin is that if you don't know what you're doing, you can blow off your leg, your friend's leg, and the legs of everyone in a twenty-foot radius.

Re: Why C++ is vastly superior to C

#68
post #17

If the author changed the title to "Why C++ is vastly superior to C for application programming", than i would agree for the examples he given in the article.

I agree with you, however most posts I have seen bashing C++ for its complexity do it from the perspective of the systems programmer as well. So it is nice to see someone showing how C++ can be superior.

Re: Why C++ is vastly superior to C

#69
post #6

Why C is vastly superior to C++: $ cat > foo.c #include int main(int argc, char**argv){ puts("hello world"); return 0; } ^D $ cat > foo.cxx #include int main(int argc, char**argv){ std::cout

Great job measuring initialization time, now how about showing real world performance differences in actual large programs.

Also, using any stream buf in c++ is more "flexible" when compared to puts(), printf(), etc due to not having to define the type. Of course, you trade flexibility for performance.
Post reply on HN