Re: Converting GCC to compilation with C++

[kaih at khms dot westfalen dot de (Kai Henningsen)]

dewar@gnat.com (Robert Dewar)  wrote on 13.07.04 in <40F4AB38.7060303@gnat.com>:

> Mike Stump wrote:
>
> > On Jul 13, 2004, at 2:25 PM, Robert Dewar wrote:
> >
> >> Well it is interesting to note that the use of dynamic dispatching
> >> in safety-critical programs is extremetly problematic
> >
> >
> > And callback functions and function pointers then are a breeze?  Or, are
> > they just as hard?
>
> They are easier. Why? Because the typical structure is that several
> callers pass a callback, and then the callback occurs. At the point
> where the callback occurs, the possible paths of control are delineated
> by the several possible calls, and MCDC testing can trace each of these
> possible paths of control.
>
> For dynamic dispatching, every call of a virtual function can
> conceptually call any of the instances of the function. But in
> practice many of these paths of control will not be excercizable
> due to (arbitrarily difficult and complex) logic constraints of the
> program. It will then be necessary to prove that these paths are
> impossible to justify not testing them. That can be very tricky.
>
> People are working hard to figure out how to address this problem,
> but there is a fundamental clash. In a certain sense, dynamic
> dispatching is about NOT being sure where the path of control
> will lead, but rigorous testing requires that all possible
> paths be understood and tested.
>
> Now why is this relevant? Well the danger is that the same
> features that make a program hard to test can make it hard
> to understand. It is of course not the case that all uses of
> dynamic dispatching are difficult to understand, and indeed
> in some cases, the judicious use of this and other similar
> features can indeed make code easier to read and maintain
> (the only objective that is interesting to me :-) However,
> lots of programmers seem to make a horrible mess of
> inheritance structures, and I continue to worry about
> allowing these general approaches in the context of a
> project on which many people work.
>
> Maybe we should all wait for the new gcj code to see how we
> all react to this experiment.
>
> After all, I certainly do not insist that all components
> of gcc be written in C (or we would have to do a big rewrting
> job for GNAT :-)

Now explain how, when you do *the exact same thing* with virtual functions  
or with function pointers, *all* the considerations you listed do not  
either apply equally to both sides, or else prefer the virtual function  
side.

Because as far as I can see, they do: if done right, the only difference  
is syntactical sugar which makes the virtual function version easier to  
read, _and_ the virtual function version has more chances to catch  
mistakes at compile time.

Comparing arbitrarily complex virtual function use with straightforward  
function pointer use is comparing diodes with Beowulf clusters.

MfG Kai