Is C++ used in life-critical systems?

[Balog Pal]

Most embedded systems don't have any support for logging. It's
not unusual, however, to "checkpoint" code, placing information
about recent operations in some sort of non-volatile fixed
length circular buffer. Whether you dare do even this once
you've found a software error, I don't know---most of the time,
I think it would be avoided in favor of terminating more
quickly.

I do a similar thing. just it is not a circular buffer but holds a single
string from the failed ASSERT. The copy can be done safely on assembly
level, dodging UB of the C++ system. Then reset is issued on the processor.
The processor boots clean and a MSR holds the reason of start, where you can
tell apart power-on, external reset line toggle, watchdog, etc from the
internal RESET instruction. On the latter condition the memory can be
checked to have content and put in the "log" -- I have one in flash
memory -- to supplement the 'startup' record.

Ability to tell whether the system is properly up from that regularly
restarting has a good value safety-wise.

 

[Man-wai Chang]

My bet to your question is NO, because of the memory needed and latency

Well it's a good thing C++ isn't just an OO language, isn't it?

From an artist point of view, yes, inheritance looks pretty.
But old C programs can still be elegant if you modularize your codes!

Don't forget that C++ is usually a pre-processor that generates C codes!

If you want speed and low overhead, C is preferred!

--
@~@ Might, Courage, Vision, SINCERITY.
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (x86_64 Ubuntu 9.10) Linux 2.6.36.2
^ ^ 18:58:01 up 2:14 2 users load average: 1.08 1.05 1.01
ä¸å€Ÿè²¸! ä¸è©é¨™! ä¸æ´äº¤! ä¸æ‰“交! ä¸æ‰“劫! ä¸è‡ªæ®º! è«‹è€ƒæ…®ç¶œæ´ (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

 

[Man-wai Chang]

About use of C++ by Lockheed for its fighter airplanes :

> ... snipped ...
So the answer seems to be clearly yes, as far as a fighter airpline is
concerned.

Don't forget that more processing power means using more electricity and
more "visible" in terms of EMF generation!

--
@~@ Might, Courage, Vision, SINCERITY.
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (x86_64 Ubuntu 9.10) Linux 2.6.36.2
^ ^ 18:58:01 up 2:14 2 users load average: 1.08 1.05 1.01
ä¸å€Ÿè²¸! ä¸è©é¨™! ä¸æ´äº¤! ä¸æ‰“交! ä¸æ‰“劫! ä¸è‡ªæ®º! è«‹è€ƒæ…®ç¶œæ´ (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

 

[Man-wai Chang]

Don't forget that more processing power means using more electricity and
more "visible" in terms of EMF generation!

More processing power also means more heat!

--
@~@ Might, Courage, Vision, SINCERITY.
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (x86_64 Ubuntu 9.10) Linux 2.6.36.2
^ ^ 19:08:01 up 2:24 2 users load average: 1.06 1.05 1.00
ä¸å€Ÿè²¸! ä¸è©é¨™! ä¸æ´äº¤! ä¸æ‰“交! ä¸æ‰“劫! ä¸è‡ªæ®º! è«‹è€ƒæ…®ç¶œæ´ (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

 

[Joshua Maurice]

 From an artist point of view, yes, inheritance looks pretty.
But old C programs can still be elegant if you modularize your codes!

Don't forget that C++ is usually a pre-processor that generates C codes!

If you want speed and low overhead, C is preferred!

Implicit in your argument is that this translation necessarily adds
bloat. I would call that a gross mischaracterization of C++ and an
incorrect blanket generalization.

C++ contains nearly all of C as a superset, so you can write C++ code
just as you would write C code, and the result will compile down to
about the same. (Yes exception support is a nasty "exception", no pun
intended.)

Yes if you write C++ code that's not like C code, then it might run
faster, as fast as, or slower. If you use virtual functions, then it
will be slower than a static dispatch. However, if you can use the
static dispatch, then use the static dispatch. The same is true in C
and C++. If you can't use static dispatch, then use virtual functions
in C++, or use function pointers in C.

 

[Michael Doubez]

 From an artist point of view, yes, inheritance looks pretty.
But old C programs can still be elegant if you modularize your codes!

And when I coded in C, I used inheritance as well although it is not
natively supported by the language.

Don't forget that C++ is usually a pre-processor that generates C codes!

CFront has been dead for the last 20 years and Comeau is hardly a pre-
processor.

If you want speed and low overhead, C is preferred!

Actually, the only true programming language is FooVoid because it
allows reprensenting all possibles potential states at the same time.
It is the LL(0) parser required to generate code that is a bit tricky
to implement.

In practice, it does nothing which is all to the good because you
don't have bugs to fix.

 

[Jorgen Grahn]

To tell the truth, I am no longer in the field so I cannot say but 3
years ago IAR only supported EC++ (and arm tools also). It may have
changed.

It depends on whether customers asked for it

I wonder who would ask for a crippled version of C++? Surely not
someone with an existing C++ code base, and surely not someone with
an existing C code base who wants to move to C++.

Looking at the IAR web page for their compiler
<http://www.iar.com/website1/1.0.1.0/467/1/>
I note that:

- they repeat the ancient Embedded C++ nonsense like "excluding
namespaces makes the runtime library significantly more efficient"
and (paraphrasing) "there's no point in implementing standard C++
because noone else does either"

- ... but IAR in fact implements something they call "Extended
Embedded C++", which *does* include templates, namespaces and the
STL ... which places the compiler in some vague area between the
Embedded C++ and C++ languages. Weird.

Possibly that compiler isn't proof that EC++ is alive, but rather
evidence that it's dead.

/Jorgen

 

[Balog Pal]

I wonder who would ask for a crippled version of C++? Surely not
someone with an existing C++ code base, and surely not someone with
an existing C code base who wants to move to C++.

Why not? Depends on what is left out. You do not need many features in the
embedded world. You do not need your codebase written for desktop/server
stuff either.

Looking at the IAR web page for their compiler
<http://www.iar.com/website1/1.0.1.0/467/1/>
I note that:

- they repeat the ancient Embedded C++ nonsense like "excluding
namespaces makes the runtime library significantly more efficient"
and (paraphrasing) "there's no point in implementing standard C++
because noone else does either"

That claim sounds fishy. But in general, namespaces is on my 'not needed'
list for embedded.

I would not cry if there was no standard lib either -- if templates are
supported so I can import my own library or any stl portions I'd happen to
like.

- ... but IAR in fact implements something they call "Extended
Embedded C++", which *does* include templates, namespaces and the
STL ... which places the compiler in some vague area between the
Embedded C++ and C++ languages. Weird.

Yeah, when I checked it the last time (~1.5 years ago) it looked perfectly
acceptable, except for the ridiculous price.

 

[Ian Collins]

Why not? Depends on what is left out. You do not need many features in
the embedded world. You do not need your codebase written for
desktop/server stuff either.

That depends on your definition of embedded. My last embedded project
used Linux and was maintained by a team of 50.

That claim sounds fishy. But in general, namespaces is on my 'not
needed' list for embedded.

I would not cry if there was no standard lib either -- if templates are
supported so I can import my own library or any stl portions I'd happen
to like.

Templates are another feature left out for "efficiency" reasons.

 

[Jorgen Grahn]

I was thinking more in terms of competence. Writing code in Embedded
C++ would be a major problem for C++ programmers used to having things
like templates, namespaces and (IIRC they left this out too)
foo_cast<T>.

For C programmers moving to Embedded C++, where would they learn the
language? You can't tear out the "non-embedded" chapters from any good
C++ book and get anything useful out of the remaining parts.

That depends on your definition of embedded. My last embedded project
used Linux and was maintained by a team of 50.

Mine too. I suppose there are really two valid but incompatible uses
of the term "embedded". In this context it's easy to see which one
we're talking about, because the "big embedded" world simply uses GCC
(which doesn't come with a -std=ec++ option).

/Jorgen

 

[Drew Lawson]

I pulled this out from another thread as it seems to be a good topic. As
there was a bunch of hypothesizing going on about the design of
safety/life-critical systems in regards to how errors ("exceptions",
tomatoe/tomato) are handled. At least one person suggested that abort()
constitutes a fail-fast (see http://en.wikipedia.org/wiki/Fail-fast)
design, which seems completely wrong.

C++ Question:

Is C++ used in life-critical systems? Expound please.

The original point in the other thread was an X-Ray machine. I
found this thread a bit late, and expected someone with closer
experience to have responded, but I don't see it.

Yes, C++ is used in systems with the potential to cause bodily
harm (if that is "life-critical").

I spent time working on two medical ultrasound platforms. While
not the life risk of X-ray, there is the risk of harm with any fetal
exams or internal (transesophageal, intravaginal, intrarectal,
cathaterized) probes. Power monitoring is essential in those cases.

General bugs get customer complaints. Power bugs get (along with
human harm) FDA audits and a potential halting of all sales.

One of the platforms was written in the early '80s in PLM, converted
to C in the mid '80s and converted to C++ in the mid '90s. (Some
C++, mostly C-in-C++.) It is no longer produced, but still in wide
use.

The other was written from the ground up in C++. That is still in
production.

Using abort() came up at one point with a new manager who didn't
see (for quite a while) how bad it is to just halt. And on that
machine, halting was the effect of abort() -- a screen that says
to call customer support or push the reset button.

Non-C++-specific Question:

Recognizing that higher-level supervision (by other systems) is surely a
common design in critical systems, thatwithstanding, how does any one
specific program handle detected bugs (the program itself detected a bug)
at runtime in released software?

Um, the software component I worked on *was* the higher-level
supervision. If it was halted, there was nothing to tell the
hardware to power down.

"Don't crash" was not something that was ever emphasized simply
because crashing (or hanging in a loop) was just Not Done.

I don't work in the field anymore. More recent system designs may
well have elements such as paired controllers that reboot a hung
partner, but that is certainly not universal.

 

[Balog Pal]

That depends on your definition of embedded. My last embedded project
used Linux and was maintained by a team of 50.

Sure. I would not call that 'embedded' in *this* context, as in my head
it maps to something like the hosted/freestanding distinction in the C/C++
standard. We have cards and boxes that have a full PC built in, with OS --
to me writing stuff there is not very different to wrtite for similar
hardware that is installed in a midi-tower case. And stripping the
keyboard and monitor does not make a difference either.

The team size also have IMO little relevance ot embeddedness and it can
be natural that more effort is needed to cover features that otherwise are
supplied by the OS (or some stock library fitting the environment out of the
box).

Templates are another feature left out for "efficiency" reasons.

For me a teplate-stripped version is no longer C++. What then we have over
C99(*) really? Member functions? That is not such a big deal alone,
easily worked around with "python style".



(*) or its approximation called 'Gnu C', that is available in gcc --
supporting inline and variables mixed with code.

 

[Adam Skutt]

Sure.  I would not call that 'embedded' in *this* context, as in my head
it maps to something like the hosted/freestanding distinction in the C/C++
standard.

That's simply a broken definition in this modern age. Embedded
doesn't necessarily ensure an OS (much less a modern one), but
attempting to draw a distinct simply because you have an OS
(especially a modern one) is equally foolish. Or the ability to
support a full C++ implementation, for that matter.

"Fixed or limited purpose" is a better (but still poor) definition, at
which point you realize how silly an "embedded C++" standard is. We'll
probably have to leave the definition to the US Supreme Court. They
don't know how to define it either, but they'll know it when they see
it.

The argument, 'these situations that I declare as embedded are what
need an embedded C++ standard', betrays itself. What is and isn't
needed for a specific application on a specific platform is a decision
that needs to be made by the application writer and/or (possibly) the
platform manufacturer, not by some arbitrary standards committee.
Especially when their standard heavily betrays a lack of understanding
of the programming language in question.

Even on "real" computers, sometimes the cost of language features or
functionality can be too high or otherwise undesirable. When that
happens, you simply don't use that functionality, you don't switch to
a language variant that lacks it.

We have cards and boxes that have a full PC built in, with OS --  
to me writing stuff there is not very different to wrtite for similar
hardware that is installed in a midi-tower case.   And stripping the
keyboard and monitor does not make a difference either.

And? Would you not consider the processor inside a tuner/digitizer
embedded? A lot of them these days run Linux on ARM or some other
small embedded chip for the purpose of control and sending the data
out (i.e., over Ethernet).

For a lot of processing tasks these days, buying a little PC with an
Atom and a high-end GPU is cheaper and better performing than
dedicated DSP processors. If I stuff that inside another box, how is
the computer not embedded?

Which, again, reinforces the notion of a silliness of an embedded C++
standard.

Adam

 

[Jorgen Grahn]

"Ian Collins" <[email protected]>

[Embedded C++]

For me a teplate-stripped version is no longer C++. What then we have over
C99(*) really?

We have C++ as it looked in the early 1990s, pretty much. I remember
using it once[1] and discarding it when I couldn't port my linked-list
container code to it in a sane way. The C original used void* a lot,
and that of course needed lots of casts everywhere when used from C++.

Stoustrup wrote in "Design and evolution" that he regretted not adding
templates (or something like them) much earlier.

Member functions? That is not such a big deal alone,
easily worked around with "python style".

RAII is a big deal, and function/operator overloading, and
private/public. Probably other things too.

Fortunately, all this are things we don't have to worry about

/Jorgen

[1] SAS/C for the Commodore-Amiga, in 1993 I think. They later added
templates as a free upgrade, *after* they had officially stopped
supporting the compiler, IIRC!

 

[James Kanze]

[...]

RAII is a big deal, and function/operator overloading, and
private/public. Probably other things too.

FWIW: private/public, in connection with member functions, are,
even today, the single most important improvement in C++ over C.
The rest is just icing on the cake---pretty nice icing, in a lot
of cases, but not as important as the encapsulation.

 

[Nick Keighley]

(I am not picking on you, but I am using your post as an example of what
I did/didn't ask for).

I've never worked on them,

OK. So you'll be doing more hypothesizing then I gather. I was trying to
curb more of that and get to the crux of the issue.

but the main school of thought for critical
systems is:

[snipped the detail of what is extraneous to the question asked]

seemed germane to me. I think the problem is your question is probably
unanswerable. That is there is no general answer. If a genuine
programming bug has been detected there is little you can do but
terminate the current "transaction" as quickly as possible. With some
processes this may not be satisfactory (eg. kill the program just
after you turned up the heat in a chemical reactor, or kill the
process that flies the areoplane)

I made concise reference to the overall design of critical systems and
noted that my question was not that at all but rather any specific
component program of such a system and how with it, it handles a detected
bug (not an error, but an honest to goodness bug).

they really really shouldn't happen. Read up on the Ariane bug its
quite enlightening (once you get past the pontificating ("if they'd
use Blub this would never have happened!")). The space shuttle
software development process is quite interesting as well.

This is the same hypothesizing that led me to create this thread. I
suggested that "fail-fast within a given program" is an oxymoron, for
starters.

I don't see why. What is clearer than "terminate immediatly"?

Then I pondered how a program is coded when it does detect a
bug, but maybe there is no such detection code in the first place though,

"never test for an error you can't handle"

 

[Nick Keighley]

I was thinking more in terms of competence. Writing code in Embedded
C++ would be a major problem for C++ programmers used to having things
like templates, namespaces and (IIRC they left this out too)
foo_cast<T>.

For C programmers moving to Embedded C++, where would they learn the
language? You can't tear out the "non-embedded" chapters from any good
C++ book and get anything useful out of the remaining parts.


Mine too. I suppose there are really two valid but incompatible uses
of the term "embedded". In this context it's easy to see which one
we're talking about, because the "big embedded" world simply uses GCC
(which doesn't come with a -std=ec++ option).

there do seem to be two sorts of embedded. I don't mind calling things
"embedded" if they sit in non-desktop boxes and don't (normally) have
keyboards or screens. So comms stuff is embedded in this sense. But
the other embedded world is the toaster and the minimal or non-
existent OS. If I applied for an embedded post they'd go strangely
silent if I mentioned Linux or Windows. Presumably I wasn't a Real
Embedded Programmer (this always sounds like a software developer who
crossed the mafia and is not serving a supporting role in a bridge or
something).

The stuff I'm working on has a tracker ball and some buttons for user
input. Is it embedded?

 

[Nick Keighley]

Sure.  I would not call that 'embedded' in *this* context, as in my head
it maps to something like the hosted/freestanding distinction in the C/C++
standard.   We have cards and boxes that have a full PC built in, with OS --  
to me writing stuff there is not very different to wrtite for similar
hardware that is installed in a midi-tower case.   And stripping the
keyboard and monitor does not make a difference either.

The team size also have IMO little relevance ot embeddedness and it can
be natural that more effort is needed to cover features that otherwise are
supplied by the OS (or some stock library fitting the environment out of the
box).



For me a teplate-stripped version is no longer C++.  What then we have over
C99(*) really?    Member functions? That is not such a big deal alone,
easily worked around with "python style".

inheritance gets pretty messy in C. Early C++ didn't have templates. I
submit you can go quite a long way without templates.

 

[Nick Keighley]

Implicit in your argument is that this translation necessarily adds
bloat. I would call that a gross mischaracterization of C++ and an
incorrect blanket generalization.

C++ contains nearly all of C as a superset, so you can write C++ code
just as you would write C code, and the result will compile down to
about the same. (Yes exception support is a nasty "exception", no pun
intended.)

Yes if you write C++ code that's not like C code, then it might run
faster, as fast as, or slower. If you use virtual functions, then it
will be slower than a static dispatch. However, if you can use the
static dispatch, then use the static dispatch. The same is true in C
and C++. If you can't use static dispatch, then use virtual functions
in C++, or use function pointers in C.

a sort written in a straightforward way in C++ is likely quicker than
a sort written in straightforward C. The C standard library passes the
comparison as a a function pointer.

 

[Ian Collins]

]

Member functions? That is not such a big deal alone,
easily worked around with "python style".

RAII is a big deal, and function/operator overloading, and
private/public. Probably other things too.

FWIW: private/public, in connection with member functions, are,
even today, the single most important improvement in C++ over C.
The rest is just icing on the cake---pretty nice icing, in a lot
of cases, but not as important as the encapsulation.

I'd say the automatic construction and destruction that enables RAII is
the single most important improvement in C++ over C. It's one thing
that you simply can't do in C. Encapsulation is just icing on the cake!