

C++ - The Forgotten Trojan Horse - silentbicycle
http://ejohnson.blogs.com/software/2004/11/i_find_c_intere.html

======
ajross
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.

~~~
old-gregg
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.

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

~~~
dryicerx
And nginx is written in C

------
kqr2
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/focus=57918)

~~~
dkarl
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.

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

~~~
siim
<http://kerneltrap.org/node/2067>

~~~
huhtenberg
> _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_ ?

~~~
makecheck
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.

------
francoisdevlin
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.

------
quizzical
This article is equating anything that is feature rich and highly competent to
being a Trojan Horse. If so, then bring on the horses!

------
sutro
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.

~~~
kqr2
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.

~~~
dkarl
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.)

------
noss
Look at all that comment spam. How lovely.

~~~
InkweaverReview
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.

------
thras
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.

~~~
adamc
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.

~~~
thras
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.

~~~
adamc
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...

