Live data from Hacker News

C++ - The Forgotten Trojan Horse

ejohnson.blogs.com

21–30 of 40 posts

Re: C++ - The Forgotten Trojan Horse

#21
post #7

Always useful reading for anyone who thinks C++ is great and can't understand all the curmudgeons who think otherwise: http://yosefk.com/c++fqa/defective.html The rest of the FQA site is good too, but the summary is the best enumeration of all the brain damage.

Believe me, those who truly believe that C++ is great, consider some of those deficiencies to be advantages. It helps to remember, that C and C++ don't exist on an "VM island", i.e. as an isolated process, like all high-level programming languages do. They are effectively extensions of UNIX-derived operating systems, i.e. they run under "UNIX VM". They even have a garbage collection of sorts: when you exit the progra…

You wouldn't build a low level filesystem in Python, however, Tahoe is a distributed file system built using python:

http://allmydata.org/~warner/pycon-tahoe.html

Re: C++ - The Forgotten Trojan Horse

#22
post #19
post #15

Earlier quoted context omitted.

Can someone post a link to his actual thoughts on C++?

http://kerneltrap.org/node/2067

> the whole C++ exception handling thing is fundamentally broken

While I completely agree that using C++ in the kernel is not the brightest idea, I am curious what's so fundamentally broken about C++ exception handling. It certainly comes with performance penalties, sometimes considerable (especially on the fast paths), but why is it flawed fundamentally ?

Re: C++ - The Forgotten Trojan Horse

#23
post #20

Earlier quoted context omitted.

Believe me, those who truly believe that C++ is great, consider some of those deficiencies to be advantages. It helps to remember, that C and C++ don't exist on an "VM island", i.e. as an isolated process, like all high-level programming languages do. They are effectively extensions of UNIX-derived operating systems, i.e. they run under "UNIX VM". They even have a garbage collection of sorts: when you exit the progra…

It's nginx that eats so little RAM. Apache is a huge!

[deleted]

Re: C++ - The Forgotten Trojan Horse

#24
post #11

This article is silly. The real reason for the rise of C++ is that "C with Objects" fit the metaphors that GUI libraries need a lot better than C. And in the end...it's not such a bad language. In the real world, you only use a small part of it on any one project. In the real world, your framework or libraries matter more than the language anyway. And in the real world, performance always matters in the end.

I don't agree on the last. In the "real world" that I am familiar with, performance is often irrelevant. Lots of programs get written that don't need to run fast or don't do enough work for performance to be an issue.

Re: C++ - The Forgotten Trojan Horse

#25
post #14
post #7

Always useful reading for anyone who thinks C++ is great and can't understand all the curmudgeons who think otherwise: http://yosefk.com/c++fqa/defective.html The rest of the FQA site is good too, but the summary is the best enumeration of all the brain damage.

OK, picked one random whine: "When an invalid program finally crashes (or enters an infinite loop, or goes to sleep forever), what you're left with is basically the binary snapshot of its state (a common name for it is a "core dump"). You have to make sense of it in order to find the bug." If you write an invalid program... Then you are doing it completely wrong! ( http://lemonodor.com/archives/2007/10/youre_doing_it…

> OK, picked one random whine:

The whole list is a one big whine that in parts is staggeringly clueless. It reads like its author has challenged himself to come up with as many "Defective" or "Very complicated" items as he could just for the sake of making the list looooong.

Re: C++ - The Forgotten Trojan Horse

#27
post #14

Earlier quoted context omitted.

OK, picked one random whine: "When an invalid program finally crashes (or enters an infinite loop, or goes to sleep forever), what you're left with is basically the binary snapshot of its state (a common name for it is a "core dump"). You have to make sense of it in order to find the bug." If you write an invalid program... Then you are doing it completely wrong! ( http://lemonodor.com/archives/2007/10/youre_doing_it…

> OK, picked one random whine: The whole list is a one big whine that in parts is staggeringly clueless. It reads like its author has challenged himself to come up with as many "Defective" or "Very complicated" items as he could just for the sake of making the list looooong.

Some of them are just wrong, and a few of the wrong ones seem to be intentionally wrong. C++ has quite a few flaws, but I've always considered the FQA to be a troll.

Re: C++ - The Forgotten Trojan Horse

#28
post #19

Earlier quoted context omitted.

http://kerneltrap.org/node/2067

> the whole C++ exception handling thing is fundamentally broken While I completely agree that using C++ in the kernel is not the brightest idea, I am curious what's so fundamentally broken about C++ exception handling. It certainly comes with performance penalties, sometimes considerable (especially on the fast paths), but why is it flawed fundamentally ?

There is some explanation here: http://yosefk.com/c++fqa/defective.html#defect-10

Almost makes sense to me, except any feature in C and C++ can be criticized this way. In the C/C++ land you have access to hardware, plus almost every resource (except maybe function stack frames) is allocated and deallocated manually. In C/C++ you can make a mistake with virtually any operation that involves pointers, buffer overruns being perhaps the most popular one. So? Dump pointers altogether?

Or take "return" - basically same problem as with "throw" (although only within one function) - it can bypass some resource deallocations.

C/C++ is like a scalpel, it requires professionalism and great, great care and you can do wonderful, magical things with it.

Re: C++ - The Forgotten Trojan Horse

#29
post #7

Always useful reading for anyone who thinks C++ is great and can't understand all the curmudgeons who think otherwise: http://yosefk.com/c++fqa/defective.html The rest of the FQA site is good too, but the summary is the best enumeration of all the brain damage.

It's amusing how people attack C++ from both directions. You get the main article apparently complaining that C++ isn't retarded simple and verbose like C. Then you also get people like in this link basically complaining that C++ isn't Lisp. Allow me to clarify: C++ is a replacement for C. C code rewritten as C++ will almost always be shorter and the same speed. The structure and function of the code will also tend t…

C++ has a high price in terms of binary incompatibility. Its mangling is (still) complex and fairly non-standard across compilers, which means that libraries are unusable unless you know how they were built and have built them all consistently. Plain C libraries, however, are generally plug and play.

To put up with the pain that is C++ mangling (which I sometimes do), I need to be using major features of C++. If you're only using C++ to make shorter, prettier code that could just as easily be C, you're creating an unnecessarily fragile binary.

Clearly C++ has its advantages, I'm just saying that you should require a lot of those features before accepting it as a language. This is especially true now that C has been absorbing some of the advantageous features of C++, such as inlining.

Re: C++ - The Forgotten Trojan Horse

#30
post #24
post #11

This article is silly. The real reason for the rise of C++ is that "C with Objects" fit the metaphors that GUI libraries need a lot better than C. And in the end...it's not such a bad language. In the real world, you only use a small part of it on any one project. In the real world, your framework or libraries matter more than the language anyway. And in the real world, performance always matters in the end.

I don't agree on the last. In the "real world" that I am familiar with, performance is often irrelevant. Lots of programs get written that don't need to run fast or don't do enough work for performance to be an issue.

Well, if we're talking "programs" as opposed to administration glue scripts, I see very few fields where performance doesn't matter. It matters for online apps. It matters for GUI applications. It matters for games. It matters for scientific software. Operating systems. Embedded apps. I suppose there are some enterprise business niche software fields somewhere where it doesn't matter -- until someone decides to write some competing software and sell it, that is.
Post reply on HN