C++ - The Forgotten Trojan Horse(ejohnson.blogs.com)
ejohnson.blogs.com
C++ - The Forgotten Trojan Horse
http://ejohnson.blogs.com/software/2004/11/i_find_c_intere.html
39 comments
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 program, the memory gets freed. And, according to Linux philosophy, launching processes or forking/dying should be quick, efficient and, in fact, desirable. Also, having many independent binary modules is the norm, so here is your runtime encapsulation.
But C family is still the only tool out there that allows you to extend an OS, i.e. for instance to build a piece of code, a single instance of which will be serving all other simultaneously running processes. This explains why Apache eats so little RAM. None of VM-based languages can do that. It's called systems programming.
Building a web-based CRM in C++ is stupid. Building a filesystem in Python is impossible.
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 program, the memory gets freed. And, according to Linux philosophy, launching processes or forking/dying should be quick, efficient and, in fact, desirable. Also, having many independent binary modules is the norm, so here is your runtime encapsulation.
But C family is still the only tool out there that allows you to extend an OS, i.e. for instance to build a piece of code, a single instance of which will be serving all other simultaneously running processes. This explains why Apache eats so little RAM. None of VM-based languages can do that. It's called systems programming.
Building a web-based CRM in C++ is stupid. Building a filesystem in Python is impossible.
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
http://allmydata.org/~warner/pycon-tahoe.html
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.
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_wrong.h...)
There are two types of peope: those who belive what they read and those who want to try out their own and then read and after that whine or ... :)
"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_wrong.h...)
There are two types of peope: those who belive what they read and those who want to try out their own and then read and after that whine or ... :)
> 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.
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.
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 to be clearer in C++.
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 to be clearer in C++.
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.
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.
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.
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.
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.
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.
Linus Torvalds thoughts on C++:
http://thread.gmane.org/gmane.comp.version-control.git/57643...
http://thread.gmane.org/gmane.comp.version-control.git/57643...
Those aren't his thoughts. Those are his thoughts morphed into a flame meant to stop people from bugging him about a particular decision he made that he believed was correct and didn't want to revisit ad nauseam.
Can someone post a link to his actual thoughts on C++?
> 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 ?
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.
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.
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.
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.
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.
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.
Never seen it happen :-)
I'm sure if he shared his actual thoughts, it would bring him some serious hassle, what with people wanting to debate with him. Much easier just to make it clear he isn't willing to be reasonable on the topic.
I'm sure if he shared his actual thoughts, it would bring him some serious hassle, what with people wanting to debate with him. Much easier just to make it clear he isn't willing to be reasonable on the topic.
I couldn't find any useful information in that thread. A couple C aficionados basically scream they don't like C++ and baselessly claim it has performance and portability problems.
This should be required reading for anyone trying to push a new language in a Java/C# shop. Don't fight the platform, instead, leverage it to your advantage.
This article is equating anything that is feature rich and highly competent to being a Trojan Horse. If so, then bring on the horses!
This is the same strategy that Clojure is now using, which is why it's the only LISP that has any chance of going mainstream.
I don't think Clojure uses the same "trojan horse" strategy, i.e. it isn't a superset of the Java language with Lisp extensions.
It does use the Java virtual machine, however, which allows it to use existing java libraries.
It does use the Java virtual machine, however, which allows it to use existing java libraries.
Implementing Java interfaces and subclassing Java classes does allow Clojure programmers to introduce Clojure into a Java organization without forcing the Java programmers to accommodate them in any special way.
(That is, as long as Clojure code can be deployed easily as jars, and as long as Clojure doesn't create any special classloader problems because of its runtime system. Those are problems that bit me hard when I used Jython code in the Eclipse plugin framework, and I imagine any dynamic language might accidentally create classloader problems unless it was specifically designed to avoid them.)
(That is, as long as Clojure code can be deployed easily as jars, and as long as Clojure doesn't create any special classloader problems because of its runtime system. Those are problems that bit me hard when I used Jython code in the Eclipse plugin framework, and I imagine any dynamic language might accidentally create classloader problems unless it was specifically designed to avoid them.)
Look at all that comment spam. How lovely.
Yeah.
Great post, but the comment spam shows that this site isn't very well maintained. Clearly the author hasn't spent much time on it in a long time.
Too bad.
Great post, but the comment spam shows that this site isn't very well maintained. Clearly the author hasn't spent much time on it in a long time.
Too bad.
It's been a long time since the last time I saw spam in a blog. Totally embarrasing.
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.
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.
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...
Kind of disappointed in HN for rating you up. Just goes to show...
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.
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.
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.