feg@clyde.ATT.COM (Forrest Gehrke) (03/22/89)
I have been experimenting (and learning something about c++) with the article in the Feb. issue of DDJ on Multitasking Kernel. I am using Zortech's v1.07 compiler. On page 45, third column, the author of this article states: "C++ supports in-line functions, but, unfortunately, the Zortech compiler does not generate in-line code in all cases." It is not clear why the author throws that comment in, as the comment doesn't seem to relate to the subject in that paragraph. Anyhow, in several of my attempts to uncover cases when the compiler does not properly handle inline, I have not found any. Has anyone found circumstances where the inline reserved word is used, the Zortech compiler will not generate inline function code? Could the author have been working with any earlier version which did not generate this code? Forrest Gehrke
johnm@trsvax.UUCP (03/24/89)
In the read.me that comes with the Zortech compiler it specifically states in the list of bugs... "Inline functions that contain any ifs, gotos, whiles, dos, fors or switches are not inlined. The code will still compile and execute correctly, however." In other words, it's a case of RTFREADME :-). John Munsch
bright@Data-IO.COM (Walter Bright) (03/25/89)
In article <42890@clyde.ATT.COM> feg@clyde.ATT.COM (Forrest Gehrke) writes: >Anyhow, in several of my attempts to uncover cases when >the compiler does not properly handle inline, I have >not found any. Has anyone found circumstances where the >inline reserved word is used, the Zortech compiler will not >generate inline function code? The compiler will generate a real function call, rather than inline expanding an inline function, in the following cases: 1. Calling it through a pointer-to-inline-function. 2. If the body of the function contains if, goto, do, for, while or switch statements. 3. If the inline function is variadic. 4. If the inline function is declared, but not defined yet, at the point of its use. It's my understanding that the only difference between this behavior and cfront's is that cfront is able to inline expand *some* functions containing if statements. It does this by replacing them with ?: expressions. It's quite difficult to inline expand a switch or loop statement, and the utility of it is poor, so it's not done. (The purpose of inlining is to gain speed, and for a loop most of the time is presumably in the loop, not in the function call.) There is nothing in the language definition to either require or disallow inline function expansion. It is purely a 'quality of implementation' issue. The only requirement is that the behavior of the program is *as if* they were all regular functions. Inline is merely a hint to the compiler. One problem with inlines: doing them is so easy and seductive that many programmers go overboard with them, generating far more than would yield a real improvement. The resulting problems are: 1. The program may wind up being unnecessarilly large. 2. Keeping all those functions in the compiler's symbol table chews up lots of memory. On a 640k PC, this is frequently the cause of running the compiler out of memory.
jeenglis@nunki.usc.edu (Joe English) (04/05/89)
bright@dataio.Data-IO.COM (Walter Bright) writes: >The compiler will generate a real function call, rather than inline >expanding an inline function, in the following cases: >1. Calling it through a pointer-to-inline-function. >2. If the body of the function contains if, goto, do, for, while or > switch statements. [... other (fairly obvious) reasons] >It's quite difficult to inline expand a switch or loop statement, and the >utility of it is poor, so it's not done. (The purpose of inlining is to >gain speed, and for a loop most of the time is presumably in the loop, not >in the function call.) Not inlining loops and switches makes sense, but why not if statements? Having functions with if's inlined could be useful in a lot of cases, for example, doing a quick check for parameter validity before executing the rest of the code. What are the technical problems with inlining if's? --Joe English jeenglis@nunki.usc.edu
bright@Data-IO.COM (Walter Bright) (04/06/89)
In article <3390@nunki.usc.edu> jeenglis@nunki.usc.edu (Joe English) writes: >Not inlining loops and switches makes sense, but why not >if statements? >What are the technical problems with inlining if's? To inline if's, it's necessary to convert them to equivalent expressions involving ?:, && and || operators. (The idea is to convert the entire function to one expression.) In fact, I asked Bjarne and he said that this was exactly what cfront did. However, I have not gotten around yet to putting in the code to do this, hence it doesn't inline if's just yet.