Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!gwyn From: gwyn@brl-tgr.ARPA (Doug Gwyn) Newsgroups: net.lang.c Subject: Re: ANSI C suggestions Message-ID: <5399@brl-tgr.ARPA> Date: Fri, 19-Oct-84 16:11:06 EDT Article-I.D.: brl-tgr.5399 Posted: Fri Oct 19 16:11:06 1984 Date-Received: Sat, 20-Oct-84 07:19:29 EDT References: <228@boulder.UUCP> <4460@utzoo.UUCP> <205@rlgvax.UUCP> Organization: Ballistic Research Lab Lines: 27 > > ... Note also that constants are still "double" unless explicitly cast > > to "float", which is a nuisance (the alternative was nightmarish problems > > in deciding the type of a floating-point constant). Not ideal, but workable. > > I presume the FORTRAN alternative (it's single precision unless specified > with an exponent whose exponent character is 'd', not 'e', like > "3.1415926535d0") was rejected for compatibility reasons; intuiting the > type from the length of the string or somesuch is, I agree, nightmarish. > The only alternative is to require it to be stated explicitly somehow; > the question is whether the default should be "double" or "float". ("long" > constants already require the length to be specified explicitly, by a > trailing "L".) I see no real problem with C floating-point constants continuing to be interpreted as double-precision. Examples: #define PI 3.14159etc. /* who knows how it's going to be used? */ float value = 1.5; /* compiler can figure this out */ double value = (float)1.5; /* throwing away precision for some reason */ float value = (float)atan2( 0.5, 1.0 ); /* args must be doubles */ Also, remember that such constants are currently doubles and any change needs to preserve this property to avoid breaking existing correct code. (float) is simple, unambiguous, and seldom explicitly required.