shankar@hpclisp.HP.COM (Shankar Unni) (11/18/89)
This is about the handling of formal parameters of type "float" in C++. The 2.0 language spec seems to imply that these floats should be treated as floats, and that any parameter passed to such functions should be passed as a float. In actuality, what seems to be happening is that in the generated K&R C code (the default), an old-style definition is put out (causing the "float" parameter to be treated by the compiler as a double), and, in the absence of prototypes, all actual parameters are also promoted to double. In addition, the translator is really spotty about casting the actual parameters to type "float" at the point of call. It sometimes does the cast, and then again, often it does not. The reason this is an issue is for C++ *compiler* writers (those that generate code without going through a C compiler). What does the language spec say about this type-rewriting? Should it happen? It is unspecified, or does the language want to commit one way or another (say, do what ANSI C does)? If C++ is supposed to behave like C in this regard, where does that leave the translator? ----- Shankar Unni E-Mail: Hewlett-Packard California Language Lab. Internet: shankar@hpda.hp.com Phone : (408) 447-5797 UUCP: ...!hplabs!hpda!shankar
ark@alice.UUCP (Andrew Koenig) (11/19/89)
In article <1000037@hpclisp.HP.COM>, shankar@hpclisp.HP.COM (Shankar Unni) writes: > This is about the handling of formal parameters of type "float" in C++. > The 2.0 language spec seems to imply that these floats should be treated as > floats, and that any parameter passed to such functions should be passed as > a float. Correct. > In actuality, what seems to be happening is that in the generated K&R C > code (the default), an old-style definition is put out (causing the "float" > parameter to be treated by the compiler as a double), and, in the absence > of prototypes, all actual parameters are also promoted to double. Yup. If you ask cfront to generate ANSI C and you have a C compiler that accepts it, it should be better about it. If your C compiler doesn't provide first-class support for `float' and your C++ compiler generates C, what can one do? > In addition, the translator is really spotty about casting the actual > parameters to type "float" at the point of call. It sometimes does the > cast, and then again, often it does not. Examples, please? > The reason this is an issue is for C++ *compiler* writers (those that > generate code without going through a C compiler). > What does the language spec say about this type-rewriting? Should it > happen? It is unspecified, or does the language want to commit one way or > another (say, do what ANSI C does)? It should behave like ANSI C. > If C++ is supposed to behave like C in this regard, where does that leave > the translator? The best one can do, faced with the task of generating C for a C compiler that only knows how to pass double arguments, is to pass floats as doubles with appropriate casts in the right places to ensure the correct values are actually passed. Cfront does a pretty good job of this. For example: extern void f(float); main() { double d = 3; f(d); f(3); f(3.0); } In each of these cases, the code generated by cfront (2.0) casts the argument to float to pass it to f. If you know of cases where this is not being done and should be, please let me know. -- --Andrew Koenig ark@europa.att.com
martino@microsoft.UUCP (Martin O'Riordan) (11/24/89)
In article <1000037@hpclisp.HP.COM> shankar@hpclisp.HP.COM (Shankar Unni) writes: >This is about the handling of formal parameters of type "float" in C++. > >The 2.0 language spec seems to imply that these floats should be treated as >floats, and that any parameter passed to such functions should be passed as >a float. > >In actuality, what seems to be happening is that in the generated K&R C >code (the default), an old-style definition is put out (causing the "float" >parameter to be treated by the compiler as a double), and, in the absence >of prototypes, all actual parameters are also promoted to double. > >In addition, the translator is really spotty about casting the actual >parameters to type "float" at the point of call. It sometimes does the >cast, and then again, often it does not. When the AT&T 1.2 version of C++ was released, there were very few C compilers which would accept function prototypes. For this reason, the translator emitted K&R declarations and definitions. However, the 2.0 implementation does have a switch to support ANSI C compilers, and will emit fully prototyped function declarations and definitions, which may be used by the underlying C compiler to ensure that arguments are passed according to the type they are declared. Hence float will be passed as float. The restriction is not in the language, and the 1.2 C++ did get people working well with prototypes. As for casts being troublesome, you are probably refering to the 1.2 implementation, which was an unsupported product from AT&T, and thus buggy. While with my former employer, Glockenspiel, I did add full support for C compilers which supported prototyping. This allowed us to avail of the improved reliability gained from telling the C compiler what was being done. Many bug fixes were done also, which ensured that the casts to which you refer, were correctly generated. The AT&T 2.0 is a much more solid product, and is now supported. They have fixed hundreds of bugs, as well as enhancing the language. Try it out and see. ----------------------------------------------------------------------------- Martin J. O'Riordan Microsoft Corporation 1 Microsoft Way Redmond WA 98052 Phone : (206) 882-8080 E-Mail : uunet!microsoft!martino