Re: procedural vs object oriented

["Ludovic Brenta" <ludovic@ludovic-brenta.org>]

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.