Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ - The Forgotten Trojan Horse

ejohnson.blogs.com

Post reply on HN
Print view View original

31–40 of 40 posts

Re: C++ - The Forgotten Trojan Horse

#31

Post by thras »

old-gregg wrote: post #10
ajross wrote: 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…

I don't know. Every time RoR slows down under barely any load, I swear to myself that I'm going to right C++ on Rails and do it right.

Re: C++ - The Forgotten Trojan Horse

#32

Post by dryicerx »

ilyak wrote: post #20
old-gregg wrote: post #10

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!

And nginx is written in C

Re: C++ - The Forgotten Trojan Horse

#33

Post by wizardofoz »

makecheck wrote: post #29
kingkongrevenge wrote: post #13

Earlier quoted context omitted.

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'…

C++ has a high price in terms of binary incompatibility.

I find this statement to be rather untrue because I think most modern compilers when forced to be ISO/ANSI compliant (i do: g++ -ansi -pedantic) ensure your code is portable across systems.

Re: C++ - The Forgotten Trojan Horse

#34

Post by makecheck »

huhtenberg wrote: post #22
siim wrote: 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 ?

One thing that I consider fundamentally broken is throw-lists: if a C++ function ever throws an exception that is not in its throw-list, the program terminates. (The only way to avoid this is to omit the throw-list entirely, so I always omit it.)

There are of course a few things wrong with this design.

One is that even deeply nested exceptions count; so if you've vetted your code and listed every exception that you throw, you're still screwed if you call a function that eventually throws something else.

This of course leads to the next problem: code evolves. Suppose you did somehow review all possible code that your function will touch, and wrote an accurate throw-list. Then next week, Jim goes into one of those buried routines and makes it throw something new; boom, you are once again at risk of terminating.

Yet another problem: suppose the messed-up throw list is in a library. Not only does this mean a library is responsible for exiting your program at a completely inappropriate point, but it might be a library that you can't easily change. So you're forced to declare implementation-specific exceptions that have no meaning to your callers. (Or just don't declare, as I do.)

The real issue of course is that terminating is a stupid behavior, even though they define terminate() to give you a point of interception. There are all kinds of reasons why you might accidentally mess up a throw-list, and since all you really gain for "fixing" this is a little code purity, it hardly seems worth dealing with severe runtime errors.

Re: C++ - The Forgotten Trojan Horse

#35

Post by makecheck »

wizardofoz wrote: post #33
makecheck wrote: post #29

Earlier quoted context omitted.

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'…

C++ has a high price in terms of binary incompatibility. I find this statement to be rather untrue because I think most modern compilers when forced to be ISO/ANSI compliant (i do: g++ -ansi -pedantic) ensure your code is portable across systems.

Which ones? I can't even make GCC 3.x and GCC 4.x link together reliably.

Re: C++ - The Forgotten Trojan Horse

#36

Post by wizardofoz »

makecheck wrote: post #35
wizardofoz wrote: post #33

Earlier quoted context omitted.

C++ has a high price in terms of binary incompatibility. I find this statement to be rather untrue because I think most modern compilers when forced to be ISO/ANSI compliant (i do: g++ -ansi -pedantic) ensure your code is portable across systems.

Which ones? I can't even make GCC 3.x and GCC 4.x link together reliably.

Well I wrote (a command-line) program that was about 2000 lines long in C++ and during most of the development period I used g++ with the -ansi & -pedantic options.

Later I was able to get my program to compile on Visual C++ with absolutely no modification.

Re: C++ - The Forgotten Trojan Horse

#37

Post by makecheck »

wizardofoz wrote: post #36
makecheck wrote: post #35

Earlier quoted context omitted.

Which ones? I can't even make GCC 3.x and GCC 4.x link together reliably.

Well I wrote (a command-line) program that was about 2000 lines long in C++ and during most of the development period I used g++ with the -ansi & -pedantic options. Later I was able to get my program to compile on Visual C++ with absolutely no modification.

Ah, that's different, that's just compilation (and yes, I've seen compilation incompatibilities too; VS usually requires code changes to compile).

I was referring to the binary interface. What I'd want to do (and generally can with C) is compile a library with any compiler, and link it with any other code, with no recompiling.

You see this all the time with Unix, say; maybe Sun compiles a bunch of stuff with their C compiler, but you can easily link to what's in /usr/lib using GCC. But with C++, it's typical for the loader to not link C++ libraries that were built differently; and if you're really unlucky, the loader won't notice and instead you'll see subtle binary errors at runtime.

Re: C++ - The Forgotten Trojan Horse

#38

Post by zmimon »

huhtenberg wrote: post #22
siim wrote: 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 ?

I'm not sure about fundamentally broken, but back when I was deeply entrenched in C++ it was clear that it is diabolically hard to write C++ code that behaves correctly in the face of all the places and times exceptions may be thrown.

There are zillions of corner cases - things like handling of exceptions thrown from destructors (remember, destructors get called implicitly as C++ unwinds the stack, possibly due to ... another exception) that get so complex and weird it is barely possible to understand, let alone correctly code for them.

Re: C++ - The Forgotten Trojan Horse

#39

Post by gaius »

thras wrote: post #30
adamc wrote: post #24

Earlier quoted context omitted.

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…

Not least because better performance means less money spent on hardware, power, cooling, less space occupied in the datacentre, etc etc.

Joe Hacker might not care about performance of his scripts on his VM he's got from a hosting provider, but you can bet they care a great deal about how many VMs they can fit on one physical host.

Re: C++ - The Forgotten Trojan Horse

#40

Post by adamc »

thras wrote: post #30
adamc wrote: post #24

Earlier quoted context omitted.

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…

Wow, quite the load of BS ego there. The average page in the wide-wide world is seldom visited and its performance doesn't matter. There are any number of GUI programs I use that are just utilities whose performance matters very little. And, yes, there is plenty of business software that needs to do its job correctly but where the performance is unimportant, or nearly so.

Kind of disappointed in HN for rating you up. Just goes to show...

Post reply on HN