Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!dayton!viper!john
From: john@viper.UUCP
Newsgroups: comp.lang.c
Subject: Re: C and Floating Point
Message-ID: <798@viper.UUCP>
Date: Wed, 8-Apr-87 14:02:54 EST
Article-I.D.: viper.798
Posted: Wed Apr  8 14:02:54 1987
Date-Received: Sat, 11-Apr-87 08:25:22 EST
References: <15958@sun.uucp> <5716@brl-smoke.ARPA> <14680@cca.CCA.COM> <790@xanth.UUCP> <788@kodak.UUCP>
Reply-To: john@viper.UUCP (John Stanley)
Organization: DynaSoft Systems
Lines: 64
Keywords: C Fortran Floating Point Parenthases

In article <788@kodak.UUCP> grodberg@kodak.UUCP (Jeremy Grodberg) writes:
 >
 >    I also don't believe that people put parenthases in their code with the
 >understanding that it won't have any effect on the order of evaluation.  
 >One of the reasons I put parenthases in my #defines is so that I can be sure
 >that that will be evaluated before anything around it. 
 >

Please add my name to the growing list of people who object to making
reordering of parenthasized equations a default standard!!!  If the
primary reason for maintaining this is the pre-existance of compilers
which do this, that is an unaceptable excuse.  The standard will
already require major changes in many compilers.  The pre-existance
of a bad idea is no excuse for maintaining it...

 >    2) *People* expect parenthases to be honored, and will be confused when
 >       bugs occur because they are not.

Exactly!  If I didn't have a reason for wanting to specify an exact order,
I wouldn't use them...  Not honoring parenthases is an inconsistancy in
an otherwise what-you-write-is-what-you-get language.

One of the primary features I like about C is that it does what I tell it
to do without placing unnecessary limitations on the constructs I create.
It's not the responsibility of the designers of a compiler to decide I
mean one thing when I explicily tell the damn fool thing I mean something
else!  That's one of the things I hate about many other languages and,
in most cases love about C.  I tend to avoid languages where the designers
of the language thought they knew more about what "should" be possible 
than I do...  Please don't standardize something that will forever
force C into the same category!!!

 >
 >     To satisfy the time critical applications, I would recommend either
 >a compile time command line option such as -Oe (optimize expressions) or
 >a reserved word #define, such as #define OPT_EXPR (which could also be
 >specified on the compiler line).  The latter would provide for code
 >transportability between standard and non-standard compilers, as well as a way
 >to compile old code on new compilers.
 >

An EXCELLENT idea!  Place the "optimization" options where they will do
the most good and the least harm.  Placing expression optimization in
the category of "options" will cause fewer peices of code to break
when ported (if they don't rely on optimization) and will, correctly,
classify code compiled with an "optimize expressions" flag as code which
may have problems if you don't use the exact same optimizations.



(SUMMARY:  (PLEASE READ THE FOLLOWING))!

  The standards committee has as one of it's obligations to define rules
that will allow writing code which will work on the largest number of 
compilers as possible with little or no change.  Allowing the compiler 
to, at it's option, totaly ignore the EXPLICIT wishes of the programmer 
is one of the easiest ways I can think of to produce a "standard" which 
unnecessarily frustrates programmers, will actualy _Cause_ portability
problems, and is, in fact not a functional "Standard" at all.

--- 
John Stanley (john@viper.UUCP)
Software Consultant - DynaSoft Systems
UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john