Would I try and use exceptions and the like on a device with a harvard architecture with 4kb of code storage and 512bytes of ram? I think not, same with RAII etc, that's a lot over overhead for such a small device.

But this is something C++ is fundamentally designed to achieve: you can simply take your C program, sometimes tweak it a little, compile it in C++ mode and get almost the same code generated (because they're not identical compilers).

You can restrict which C++ constructs you use. There's no reason not to use classes if you were otherwise going to make a struct called "foo" and then a bunch of functions called "foo_init()" "foo_get_c()" etc. I see this all the time and it makes me do a facepalm for real.

Why, why, why would you restrict yourself to just plain C if you know exactly what these C++ constructs are going to do? Why would you use just plain C if that would mean less type safety, and more code? Why would you use just plain C if it got in the way of rapid development? Isn't that just language zealotry? These kind of development tools decisions are bad for you and others who use your code.

Most of the rest of your post I could agree with, but not this, there is a reason we code in c not c++ in embedded systems.

Who's "we"? I've been very successfully coding in C++ in embedded systems for over a decade, and I'm talking devices with anything from just a few KB of memory. If you don't understand what language structures do to code generation, you shouldn't be coding for embedded systems in either language. If you think C++ cannot be used for embedded systems, you don't understand the language at all.

Except C++ is not slower than C... It's actually equally fast, and can give a lot of performance optimizations with a fraction of the code needed to do the same on C.

It's even better than that. There's extra type checking and tighter rules on aliasing in C++ (unless you turn them off), so it can actually generate faster code. If you trivially convert a C program to the slightly less relaxed rules of C++, you should expect at least the same performance (if not, file a bug with your compiler provider), and often better.

I agree with the sentiment that anyone who thinks C++ is slower then C understands neither. It perfectly demonstrates their lack of understanding.

Fortran is alive and well. The 2008 standard just came out. Lots of people use it. Like C++, it is not the best language for every problem.

Hah, I'm not sure why I even wrote that now. You're right: it's still in active use for number-crunching by a large number of people.

It's because I've never used it in employment, ever. I get the same from folks who grew up with nothing but plain C or Java: they think C++ is dead because they never see it being used. They're surprised when they learn that practically everything they use on an hourly basis has C++ running at the heart of it.

I don't understand why Objective C is considered a good alternative to C++. Why not use both? You get the advantages of C++ type checking and encapsulation, while also having the runtime dynamic binding of Objective C.

Sadly, every time C++ is mentioned on Slashdot, we get a flood of unoriginal, boring comments about how bad it is. These usually come from people who either don't understand why the language exists, or have just plain never used it. But they heard it sucks somewhere and all the cool kids in the gang are saying it sucks, so they should join in the bullying.

So far, no language can replace it. If you don't understand this, you don't understand the class of programming problems it solves. C++ is a language designed for static compilation. It doesn't run in a VM. It isn't managed. This makes it great for system code (drivers, kernels), high performance, and "raw" environments. It is designed to be "wysiwyg": a line of code will translate to a sequence of unsurprising assembly if the programmer is experienced enough. It is designed to allow all that and still have high level features to reduce lines of code, improve type safety, and increase modularity.

There are good reasons it's still one of the most commonly used languages for games, kernels, embedded devices and high performance apps: it really is good at them. It's not just momentum and "lock-in". There have been plenty of languages with bigger backers that died because they were bad or just merely obsolete: Pascal, COBOL, Fortran as quick examples. Ada is still out there simply because the military backs it, and I wouldn't be surprised if that changes.

There are plenty of languages which are better in some domains: Java has the advantage of a managed VM, and Python has a neat syntax and can achieve a lot in few lines of code, as just two examples. However, you'd never write system code in Java or Python. You'd never write something high performance in Python. You'd never settle for the critical path of a high performance application being written in Java. Well, some people do, but they're either kidding themselves, or they don't really have a high performance application.

I really, really would love someone to design a language which fulfills everything C++ does, but at the same time fix up its sometimes arcane syntax and removing the shotguns constantly pointing at your feet. But until then, I'm happy with the language that makes my every day job that little bit easier. If you find that funny, then you're the target of Stroustrup's interview: you need to stop being foolish and give it a chance. I pity all the people I've met over the years who are convinced they know the "best" language and will stick with it forever. Or those who consider C better for every problem which C++ would be suited. Happy job hunting to them - that attitude will catch up with you some day.

The OP asked for the make of the CPU, in this context the CPU is the Hummingbird core. A SOC contains far more then a CPU thank you.

The OP asked no such thing. In what context is the CPU thought of as just the application core?

You might as well call a Xilinx Virtex 5 FPGA a PowerPC 440, because it has one in it. That would of course ignore the gigantic array of parallel multipliers and programmable logic it has. Calling the A4 a Samsung Hummingbird is disingenuous.

The CPU in the Iphone is the Samsung developed and made Hummingbird core (bog standard ARMv7).

If you think a smartphone SoC is defined just by the spec of the application core(s), which are a tiny fraction of its size, you've got it wrong. Hint: two SoCs with identical application cores can be vastly different in performance due to all that other stuff in the chip.

Let's look at the following:

1. By definition, an internet service provider IS a man in the middle. To everyone whining about using this method - welcome to the real world. A man in the middle approach is the easiest one for the man in the middle to take.

No. By definition, an internet service provider is a bridge and router. It is not supposed to mess with your traffic. It is not supposed to be looking at these layers. Comcast has shown many times they don't care about that, though. They messed with all HTTP traffic by sending RST packets at you to upset bittorrent, also breaking normal web connections, and anything else which happened to be on port 80, e.g a lot of games. They messed with DNS to redirect to their own advertising sites for failed lookups. Now they're messing with HTTP to insert their banners. What will that do to traffic which happens to be HTTP but isn't web? News for you (and from your comment this probably IS news for you): the internet is not the web. That'll break bittorrent, games, maybe even iTunes, twitter apps, facebook apps, simple wget/curl transfers, and anything else that just happens to be HTTP on port 80.

2. Perhaps the ISP should just terminate the accounts of users of infected machines, since I am sure running an infected machine on the net is a violation of the TOS somewhere.

Yes, that's what they should actually be doing. It's in the ToS and if they have a machine connected which is degrading their network and/or being used for malicious attacks on other computers connected via their network, they are completely in their rights to disconnect them. This stinks of them trying to save money from support calls, sending out letters, hey even automated voicemail (which they do ANYWAY) or email.

OR they could just cut them off until they call tech support. OR they could filter the traffic, seeing as they've got enough of a stateful packet inspector in place to a) identify and b) modify your HTTP connections anyway. They just proved they can do it!

I WANT them to break the service and force people to upgrade, instead of continuing to spew their filthy zombie attacks all over the net. The more dramatic and attention getting, the better. Face it - your mission critical systems should not be on a residential account anyway, RIGHT? That's what the premium priced business packages are for... So what if grandpa has to click on some links to download some software and fix his machine before he can read his paper today. It's worth it to clean up the net.

I have a theory that anyone using the phrase "face it" actually knows that what they're suggested is absurd. You don't seem to understand exactly what's being done here. There's plenty of ways for them to solve this issue, and this tactic is just plain wrong.

Hell, this drops their "neutrality" altogether. They're actively inspecting traffic and inserting their own. I reckon that opens them up to being liable for it, too.