Is C++ used in life-critical systems?

[antred]

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!

--
Ian Collins

I second that! Personally given a free choice, I refuse to even CONSIDER using a language that doesn't support RAII. Of course, I'm not always so lucky.

 

[Marc]

(This news server sucks. I thought this thread had been abandoned and I
was going to let it go for another day, but lo and behold, old replies
show up in my newsreader -- when, I'm not sure, but surely not timely).

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

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
(seehttp://en.wikipedia.org/wiki/Fail-fast) design, which seems
completely wrong.

C++ Question:

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

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?

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.

As I thought it might to a number of other posters to answer as he did,
so I tried to clarify.

I think the problem is your question is probably
unanswerable.

I know that it is answerable and I know where to get the answer. I could
have asked too abstractly though, a little bit intentionally so also,
because I wanted to get answers from anyone(s) that know this stuff like
the ABC's, and from what I've seen so far in response, those people don't
hang out in here, which I can understand having been an engineer in an
unrelated domain and regarding programming like a tool in a toolbox.

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.

Can you give an example of that? This is an aside, but very interesting,
start a new thread and direct me to it please. In that new thread, you
will give an example of a bug, and.. whatever else. Have at it! (OK,
maybe it is not so off topic, but it looks like a "bookmark" of sorts to
me).

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)

No hypothesizing please.

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.

I am seeking first-hand knowledge and specifically tried to curb the "I
read about it, and it went like this..." kind of response. I want to know
from the guy who built that, not from the guy who wrote about it. I know
where to find the answer I seek, BTW, I am too busy to go off in that
direction right now though, so I asked here, and I knew soon after I
posted the OP that this was the wrong place to ask the question. It's not
a (direct) programming language question.

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

Have you seen the movie "The Terminator"?

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

You must be quoting other people, because that doesn't sound like my
thoughts. Your dogmatic quote though does hint toward the "domain" of the
answer to the OP though, I think.

Well said(?).

 

[Marc]

[...]
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.

Just a reminder: there was no bug in the Ariane's software.
Management decided to just reuse it in a different context: the
software did what it was supposed to do, for the system it was
written for. (In other words, stating that there was a bug in
the software is like saying that your C++ compiler has a bug
because it doesn't correctly compile someone's Ada program.)

It is an interesting point with regards to the the question at
hand: at a larger level, the requirements of the system are to
auto-destruct if a bug is found. (The Ariane auto-destructed
because the software determined that the systems providing its
input were defective, since the values were impossible.) If you
aren't sure that you have full control, better to auto-destruct
than to risk crashing into a populated city.

Apparently it is not only easy to talk a game, but the desire to do so
overwhelms the desire to stay on topic! I specifically asked for
responders NOT to do this! wtf?

 

[Marc]

I don't know how one could prove that this or that is the most
important improvement. But I agree they are both important.
I tend to agree more with Mr. Kanze, say about pair programming,

What did he say about "pair programming?". Suggestion, start a new thread
about that thing and I'll probably drop by (that's a warning, not a
promise).

than Mr. Collins, but in this case, am somewhat sympathetic to
Collins' point of view.

What is his point of view? Say in your NEW THREAD.

 

[Marc]

And even with CFront, Stroustrup argued (in "Design and Evolution
...", in 1994) that it wasn't a preprocessor -- it simply compiled to
C code instead of machine code.

He was not arguing, he was telling (teaching for those who don't know).
THAT is what a compiler does: translates from one representation to
another. If anyone wants to know if something is a compiler or not, just
ask ($), and I'll tell you! And I DO know and consider it fundamental
(because for what I do, it IS fundamental).

Move this tangent to Pedantic3, and are they teaching this in CS 101 yet?
Colleges, pfft.

Now get your sorry ass off of my land.

 

[Marc]

C code is just a convenient "intermediate" language.

OK! So your epitaph has been written! James Kanze said, "C code is just a
convenient "intermediate" language". May he rest in peace, but how could
he after blathering THAT!! James, you don't want to be that guy rattling
chains on stairways, well, it's all good, nevermind.

 

[Marc]

lots of the pattern stuff is pretty difficult to do in C

C is inadequate. You are proof of that. Eh? Was it a typo that you posted
to C++ instead of C? Hmm?

this is untrue.

But, think about it, not so untrue! What did Sally Field say? Oh yeah,
it's not the truth, but it's accurate.

I believe heavily templatised C++ has beaten Fortran in certain
numerical applications. Templates doen't have to be slow.

You seem hesitant about such baptism. (?).

 

[Ian Collins]

On 12/30/10 11:46 PM, James Kanze wrote:

]
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!

>
The two are related; without the encapsulation, I doubt that
automatic construction and destruction would work. They're both
related to the idea that everything which happens to objects of
the class type is through members.

Why? An otherwise POD struct can have constructors and destructors.

I suspect the different opinion is related to the size of the
projects we've worked on, however.

That I doubt. I've worked on projects from a team of one to many hundred.

I remember back when I was
programming in C: I'd define a struct and a set of functions to
manipulate it... and then cross my fingers that no one accessed
it except through the functions I'd provided.

The idiomatic way is to to use an opaque type and force the user to use
the functions provided.

In smaller
projects, you may have more control over the programmers, and be
able to ensure that this doesn't happen. And ensuring the
initialization and automatic destruction---regardless of the
path which causes the variable to go out of scope---is an
important feature. When I said the rest is just "icing on the
cake", I was thinking of things like inheritance and templates:
both very powerful tools, but not as important as the
encapsulation (in the larger sense, including the idea that the
client cannot use an uninitialized instance of your object, nor
abandon an instance without proper cleanup).

My point was that all of the above can be implemented in C. Automatic
initialisation and destruction can't. So it presents us with a truly
new tool.

 

[James Kanze]

On 12/31/10 10:06 PM, James Kanze wrote:

[...]

Why? An otherwise POD struct can have constructors and destructors.

Yes, but there's no real point in it (except maybe syntactical
sugar for destructors), since it can't enforce any class
invariants.

[...]

The idiomatic way is to to use an opaque type and force the user to use
the functions provided.

Which imposes dynamic allocation, which creates another set of
problems.

 

[Ian Collins]

On 12/31/10 10:06 PM, James Kanze wrote:
[...]

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!
The two are related; without the encapsulation, I doubt that
automatic construction and destruction would work. They're both
related to the idea that everything which happens to objects of
the class type is through members.

Why? An otherwise POD struct can have constructors and destructors.

Yes, but there's no real point in it (except maybe syntactical
sugar for destructors), since it can't enforce any class
invariants.

[...]

The idiomatic way is to to use an opaque type and force the user to use
the functions provided.

Which imposes dynamic allocation, which creates another set of
problems.

Never the less, it does the job and is very widely used.

The solutions may not be pretty, but C can do everything C++ can except
for automatic construction and destruction.

 

[Balog Pal]

Never the less, it does the job and is very widely used.

Yes, in general, but upstream we were talking embedded (-like) systems,
where such use is ways narrower. For a set of reasons like very little RAM,
absolute need to have the memory block, need within limited time frame,
limited access to library from portions of code (i.e called from IRQ
handler), etc.

The solutions may not be pretty, but C can do everything C++ can except
for automatic construction and destruction.

Often at the cost of hardly readable code. What is not welcome in
life-critical systems either.

 

[Ian Collins]

Yes, in general, but upstream we were talking embedded (-like) systems,
where such use is ways narrower. For a set of reasons like very little
RAM, absolute need to have the memory block, need within limited time
frame, limited access to library from portions of code (i.e called from
IRQ handler), etc.

Often such systems don't have a C++ compiler available! On a small
system, the use of an opaque type need not impose dynamic allocation, a
pointer to a static object can be used.

Often at the cost of hardly readable code. What is not welcome in
life-critical systems either.

The constraints of small systems often lead to "dense" code. One of my
best was an encoder/decoder (in assembler) that used different paths
through the same code for encoding and decoding.

 

[Peter Remmers]

Am 04.01.2011 07:21, schrieb Marc:

He was not arguing, he was telling (teaching for those who don't know).
THAT is what a compiler does: translates from one representation to
another. If anyone wants to know if something is a compiler or not, just
ask ($), and I'll tell you! And I DO know and consider it fundamental
(because for what I do, it IS fundamental).

Move this tangent to Pedantic3, and are they teaching this in CS 101 yet?
Colleges, pfft.

Now get your sorry ass off of my land.

What TF is wrong with you?

You come here asking for responses and complain if you don't like them.

"I specifically asked for responders NOT to do this! wtf?"

You act like you are king of your little thread. You try to dictate what
people are to do.

"What is his point of view? Say in your NEW THREAD."
"In that new thread, you will give an example of a bug"

You threaten people.

"start a new thread about that thing and I'll probably drop by (that's a
warning, not a promise)."

You make fun of people.

"May he rest in peace, but how could he after blathering THAT!!"

and of a whole class of people.

"Move this tangent to Pedantic3, and are they teaching this in CS 101
yet? Colleges, pfft."


Maybe it is you who should get his sorry ass off this newsgroup or stop
acting like an arrogant asshole.


Peter

 

[Nick Keighley]

On 12/31/10 10:06 PM, James Kanze wrote:

    [...]

Why?  An otherwise POD struct can have constructors and destructors.

Yes, but there's no real point in it (except maybe syntactical
sugar for destructors), since it can't enforce any class
invariants.

struct Point
{
Point(double x_=0.0, double y_=0.0): x(x_), y(y_) {}
double x;
double y;
};

the constructor makes for slightly prettier syntax.

    [...]

The idiomatic way is to to use an opaque type and force the user to use
the functions provided.

Which imposes dynamic allocation, which creates another set of
problems.

 

[Nick Keighley]

You seem hesitant about such baptism. (?).

I'll not bother to respond to the rude bits but this I simply don't
understand. Are you saying I'm correct that C++ template code can beat
Fortran in numerical applications? I havn't personnally seen such code
but I've heard of it. What do you expect to say.

[I expect you to behave like an asshole]

 

[James Kanze]

On Jan 5, 10:56 am, James Kanze <[email protected]> wrote:

[...]

struct Point
{
Point(double x_=0.0, double y_=0.0): x(x_), y(y_) {}
double x;
double y;
};

the constructor makes for slightly prettier syntax.

That's what I mean by "syntactical sugar". It's certainly more
convenient to use the class with the constructor, at least in a
lot of cases. (I think that the new initializer syntax will
change this, but until we can use it portably...)

Anyway, with regards to the question whether
constructors/destructors or encapsulation is the most important
innovation in C++, compared to C: it occurs to me that this
could very well depend on programming style. I tend to write
very short functions, using single entry/single exit, so (in the
absense of exceptions) constructors/destructors are really just
syntactical sugar. The fact that the destructor is
automatically called is quite convenient, but it really links in
with the idea that I impose a specific protocol on my clients:
they can't do just anything with my class, but have to conform
to the protocol that I have defined. If you don't use single
entry/single exit, and have returns all over the place (and
yes, I know that there are intermediate positions, then
destructors become very, very important. And of course, once
you add exceptions to the mix... Exceptions can't really be used
at all without some sort of "finally", and (IMHO, of course),
destructors are a lot more elegant and practical than a finally
a la Java or Modula-3.

 

[James Kanze]

On Jan 4, 6:28 am, "Marc" <[email protected]> wrote:

[...]

I'll not bother to respond to the rude bits but this I simply don't
understand. Are you saying I'm correct that C++ template code can beat
Fortran in numerical applications? I havn't personnally seen such code
but I've heard of it. What do you expect to say.

A lot depends on the compiler, and a lot more work has been
invested in Fortran compilers than in C++ compilers, at least
with regards to optimizing numeric applications. On the other
hand, *if* the compiler doesn't do cross module optimization
(and a lot still don't), then C++, using templates or inline
functions wil allow the compiler to see a lot more. And the
amount a compiler can optimize depends a lot on how much it can
see. (Interestingly enough, the template metaprogramming
technique used in libraries like Blitz++ actually predates
templates. I've seen code which did the same thing using
virtual functions. And with at least one, very old compiler,
the version using virtual functions actually outperformed the
template code---to be frank, I don't know why: I would have
expected exactly the same code as long as the compiler actually
did inline, and the template version to be faster as soon as it
stopped inlining.)

 

[Adam Skutt]

Which imposes dynamic allocation, which creates another set of
problems.

You should tell that to the C language committee (FILE), Microsoft
(HANDLE and many others), the various UNIX guys (sem_t, everything in
pthreads, many others).

If you want enforced opaqueness, sure, dynamic allocation is
necessary, but forced opaqueness is hardly necessary.

Adam

 

[James Kanze]

You should tell that to the C language committee (FILE), Microsoft
(HANDLE and many others), the various UNIX guys (sem_t, everything in
pthreads, many others).

Most of which are allocated dynamically. (FILE in any case; you
can only use FILE*, not FILE. And HANDLE is just Microsoft's
name for a pointer to a dynamically allocated block.)

 

[Ian Collins]

Most of which are allocated dynamically. (FILE in any case; you
can only use FILE*, not FILE. And HANDLE is just Microsoft's
name for a pointer to a dynamically allocated block.)

Most, yes. But dynamic allocation isn't imposed.