NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/lang/cplus/17931

Text File | 1992-12-14 | 3.2 KB | 74 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
From: [e-mail] (John MAX Skaller)
Subject: Re: What is Object Oriented Programming? Is C doomed?
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: extro.ucc.su.oz.au
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 14 Dec 1992 19:18:12 GMT
Lines: 61

In article <[e-mail]> [e-mail] (Jim Adcock) writes:
>In article <[e-mail]> [e-mail] writes:
>|I believe it was Ed Yourdon who first said:  "it is far easier to optimize a
>|correct (i.e. working) program than correct an optimized program".
>|
>|  (2) What Youdon said was correct?
>
>No, because it is easy to construct correct programs that are practically
>impossible to optimize and it is easy to construct optimized programs that
>are practically impossible to correct.  The only way to make either correctness
>or optimization "easy" [or even *possible*] is to plan, design and build to
>make both possible from the start.  Given that a program is designed to be
>easy to optimize, and given that a program is designed to be easy to correct,
>then either task becomes easy [or at least *possible*]
>

    Actually, I believe the two are intimately related.
Imagine a program with an array access

    ... a[i] ...;

For the program to operate properly, i must be in bounds.
To ensure an invalid access will terminate the program gracefully,
the compiler inserts a run-time bounds check. This doesnt
make the program correct, nor fast, but it does ensure a certain
class of bugs will be detected at run-time.

Now to optimise the program we prove to the compiler that i
*must* be in bounds. Then the compiler will remove the run-time
check, as it cannot be useful.

    What have we done? We have simultaneously proved a component
of the program correct (in some sense) and at the same time
optimised it.

    (A really smart compiler could do the proof by itself.
In the case of a lazy programmer and dumb compiler, we could just assert that
i is always in bounds---at least the assertion is then explicit
in the code.)

    This is the approach A++ takes to things, although C++
turns out to be too complex to reason about .. the idea seems
sensible to me. It is vaguely the same thing that happens in C++
when we cast away const (or some other naughty cast).
(*I* the programmer *know* that this is OK ..)

    Or, when a derived pointer converts silently to a base pointer
(*I* the compiler know this is OK --- you dont have to tell me).

    Eiffel has formalised this to some extent, at least providing
an assertion syntax (even if the run-time checks cant be optimised away).
Wouldn't C++ benefit from this too?




--
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         [e-mail]
    Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------