Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!van-bc!rsoft!mindlink!a269
From: a269@mindlink.UUCP (Mischa Sandberg)
Newsgroups: comp.os.msdos.programmer
Subject: Optimization (was: Re: TC++ Bug)
Message-ID: <2587@mindlink.UUCP>
Date: 22 Jul 90 22:54:07 GMT
Organization: MIND LINK! - British Columbia, Canada
Lines: 29

There seems to be a broad opinion that optimizations are some
form of cheating on source compilation, and caveat emptor.
Having worked with Fortran G, Bliss-32 and different levels of
optimizing C, it took me a while to realize how this low
view of optimizing came to be.

It's true, "C" allows you to do many quick and dirty things with
pointers. Discounting really gross things (like the assumptions
that implementations of "varargs" like to make), it may come
as shock to many MS-C users that compilers of languages with
pointers and address-of operators actually can be smart enough
not to try an optimization where it may be risky. Bliss, for
example, optimizes the bejesus out of code (it tends to produce
better code than can be assembled "by hand") and is trustworthy
enough to write OS code in. Hmm, that puts into a different
light the rumours of why OS/2 had to be done in assembler :-).
It's a pretty wretched development philosophy if MS has to
document IN THE MANUALS that optimization will barf at
trivial cases like
        for ( i = 0; i < limit; i++ )
                if ( x != 0 )
                        a[i] = 1/x
for x == 0 ( admittedly bozo code, but ...)

I'm not aware of what optimization (as opposed to straight
code-generation) bugs are in TC++, but if they are comparable,
might I suggest that developers VOTE WITH THEIR FEET on
such outrageous abuse by compiler developers. Esp. considering
products that are at version 6.0 (or higher, soon, no doubt).