LR>consulting job I get calls on during the last 2 years states they want 
"C/C+
LR>programmers.  I keep thinking this is a mistake on the part of the people
LR>coming out with kind of job spec but perhaps I am in error.
LR>Is it plausible to write such RT apps in C++ - and still meet real time
LR>criteria?  I am not sure.  Perhaps some else here can comment on this.
Over the years, there has been quite a bit of discussion about that for
embedded or RT systems, and the general answer is:  No.  Too much can be
hidden by the compiler.
Even if you are very careful about what you write, you still can't be
sure exactly how it will behave unless you go through the resulting
.asm and check what the compiler is actually doing.  You can't afford
any surprises, and C++ is famous for them.
If you leave out OO, classes, operator overloading, etc., then it does
become quite a bit better.  Of course, by that point, you are left only
with C.  Of course, even C can have problems in that area, too.
And with caches.... Oh boy.. Caches.  I was going through some back
issues and I came across an article describing the effects a cache (and
other things) can have on a simple interrupt routine.  It was coded in
C, but it could have been done in any language.
The author found numerous mistakes in the Intel ref books concerning
instruction clock cycles, but as near as he could figure, each call of
the ISR should take about 104 cycles.  The actual timed result gave 148
cycles at best. At worst, he got 272 cycles.  Then, with the caches
turned off, it was 484-508 cycles. Then with you get a TLB miss, that's
additional cycle times.  And when it's running under a memory manager
(such as QEMM, EMM386, etc.) it becomes even worse.  With QEMM, the best
he got was 368 cycles (with TLB and cache hits) and 900 cycles (with TLB
and cache misses)!
If the system is big enough for you to be considering C++, it's probably
big enough to have already totally lost all determancy anyway.
--- QScan/PCB v1.19b / 01-0162
---------------