Re: procedural vs object oriented
- From: "Ludovic Brenta" <ludovic@xxxxxxxxxxxxxxxxxx>
- Date: 27 Apr 2006 03:42:10 -0700
Dmitry A. Kazakov wrote:
On Thu, 27 Apr 2006 07:22:21 +0200, Ludovic Brenta wrote:
According to Robert Dewar during FOSDEM, nobody uses OOP in avionics
software, because the uncertainty inherent to dynamic dispatching
hinders certification. Is someone on this newsgroup in a position to
give a counter-example?
Can't tell about avionics, but what uncertainty of dynamic dispatching is
meant? Or, maybe, "certification" is the context of? Then which
certification, according to which criteria?
Dynamic dispatching, by definition, means that you don't know which
subprogram you call at run-time. The compiler guarantees that the call
will succeed (i.e. that there exists a subprogram to dispatch to), but
there is uncertainty about which one it is.
DO-178B does not prohibit dynamic dispatching; it only requires that
the program be completely deterministic, and it requires the software
developers to provide reasonable proof that the program is indeed
deterministic.
If you use dynamic dispatching in a program, you must therefore prove
that you know precisely which subprogram you call each time you execute
the dispatching call. At DO-178B level A, you must also prove that the
machine code in the executable program dispatches correctly and in a
deterministic way, in bounded time and memory conditions. This
additional burden of proof is on the developer. That's what I meant
when I said that dynamic dispatching hinders certification.
The question of "how to I use dynamic dispatching while keeping the
certification costs reasonable" is quite interesting, complicated, and
has received a lot of thought, but no clear answer has come out of it.
So, for now, the only clear-cut answer in the conservative world of
avionics is, "you don't."
Talking about uncertainty in general, what about "inherent uncertainty" of
a procedure call? Can you tell which procedures will be called and when at
run time? If you can then, you can also do it for dispatching calls. Are
generic bodies more certain? With "with function "*" (Left, Right : Foo)
return Foo"? Really?
A static procedure call has no uncertainty: when you read the program
source, you know exactly which subprogram is called, even in the
presence of overloading.
When you instantiate a generic, you also know exactly which subprogram
you pass as a parameter. Again there is no inherent uncertainty here.
At Barco, our coding standards prohibit access-to-subprogram values,
and require all generics to be preelaborated. Thus they eliminate all
uncertainty and make all subprogram calls statically deterministic.
Needless to say, our coding standards also prohibit dynamic
dispatching.
--
Ludovic Brenta.
.
- Follow-Ups:
- Re: procedural vs object oriented
- From: Dmitry A. Kazakov
- Re: procedural vs object oriented
- From: Maciej Sobczak
- Re: procedural vs object oriented
- References:
- procedural vs object oriented
- From: Ananth the Boss
- Re: procedural vs object oriented
- From: bh
- Re: procedural vs object oriented
- From: Ludovic Brenta
- Re: procedural vs object oriented
- From: Dmitry A. Kazakov
- procedural vs object oriented
- Prev by Date: Type safety, C++ and code generation
- Next by Date: Re: procedural vs object oriented
- Previous by thread: Re: procedural vs object oriented
- Next by thread: Re: procedural vs object oriented
- Index(es):
Relevant Pages
|