It's very simple, really.

C++ is a superset of C. Anything you can do in C, you can do in C++. The performance overhead of C++ does not exist, until you start using specific C++ features like virtual member functions, but if you use them in place of the equivalent C construct (function pointers) again you have absolutely zero overhead. I've heard all kinds of nonsense about C++. The idea that it produces memory fragmentation comes from a misunderstanding regarding the "new" operator, an assumption that because it's provided by the language, not only must it be used, but it must be used in its default implementation which is essentially a wrapper for malloc(). The truth is that C++ does not force any memory allocation schemes on you. You can allocate objects on the stack, in global arrays, inside structures, inside other objects, etc. The idea that it introduces vulnerabilities because of the order in which static globals are constructed is equally silly; this will only ever be a problem when the programmer does not know the language he is working in and makes false assumptions. The solution is simply to avoid globals altogether; globals are awful design anyway, even in plain C.

In my experience the underlying issue is that embedded developers tend to be bad programmers. Go ahead and rip my head off, but I've seen enough embedded code to say that with a clear conscience. There is simply no good argument for stubbornly clinging to C, except not having the experience to work with C++ (or being forced to by a manager who doesn't know better, or supporting legacy code that wouldn't mesh with new OO code, etc., but you get my point).

An embedded system is not easily conceptualised in procedural terms, but it is perfectly modeled in object-oriented terms.

OK, since no one else seems to have read this article critically enough to have anything to say, I'll put in my two cents' worth. The author says "...you need to integrate the Windows Embedded CE Radio Interface Layer (RIL) driver with the Windows Embedded CE Cell Core module that includes the RIL proxy." The first problem I have here is the term "proxy" has no clear and unambiguous meaning in the context of embedded programming (just do a Google "define: proxy" for yourself and see if you have any better luck than I did); I don't think it is referring to a "proxy server" in the classic (network) sense, probably more of a service that runs under Windows CE (love that acronym "WinCE"!), something like what you might refer to under Linux as a daemon perhaps. But my issue is far more than a question about the author's use of arcane terminology which is perhaps more suited to the world of PCs than embedded devices. It appears that he has forgotten that his audience is embedded programmers here, folks for whom terms like "determinism" and "hard real-time performance" actually MEAN something. How the heck is one supposed to determine "real-time performance" when all the programmer is reduced to is writing a proxy driver rather than calling a deterministic subroutine? The general premise that the embedded programmer "shouldn't be responsible for" such performance issues to the manager who employs him rings very hollow indeed; if he ISN'T then who IS, some nondescript programmer in Redmond who is totally unaccountable to anyone!? How are we supposed to "do our jobs" and provide guaranteed system performance to management when our lives are filled with "intangibles" like this? How is this article helping, will the manager on my next project accept this as the excuse why I can't meet OR EVEN DEFINE acceptable system requirements (I certainly doubt it)? Why do we even have to put up with such "unaccountable" architectures, and why can't Microsoft ever "get it"? I realize that the author isn't responsible for that company's marketing decisions, but if he's writing here he AT LEAST ought to acknowledge this approach's shortcomings,and suggest MEANINGFUL ways of dealing with them. Otherwise I can just open my mailbox and get all the marketing hoopla I need, without having to pick it out of the technical sources that I actually take the time to read. Sorry!