TITLE: why bother with inline (Newsgroups: comp.lang.c++, , 20 Nov 96) From - Fri Nov 22 07:55:03 1996 MOEN: Hossein Moein (hmoein@jusdnews.fir.fbc.com) wrote: > : I think it was a mistake to make `inline' a part of the C++ language. > : Any comments !? KLATCHKO: Lron@crl.com (Ron Klatchko) > I've always felt that inline has more to do with the nature of C/C++ > as a language that compiles a group of modules separately and then > links them together into a single unit. > > inline tells the compiler the even though it sees the definition > multiple times not to have the linker give a multiple definition > error (much like static). BJARNE: bs@research.att.com (Bjarne Stroustrup) It is often pointed out that a compiler can do a better job at determining what functions ought to be inlined than a programmer can. However, it has been my experience that compilers usually don't. Giving programmers a simple and portable means of specifying an optimization is therefore a win. Also, a compiler has a harder job inlining than most people assume. For example, should it optimize for time or speed? How does inlining affect caching behavior? How does program size affect paging bahavior? How would a compiler optimize code in a dynamically linked library adn also in a main program if a function definition could occur only once in a program? Given 'inline' a programmer can experiment and measure. Without 'inline' some other means of control would be needed for people who needs finetuning - and that 'other tool' would be more complicated and not portable across platforms. Given that C++ does not assume a smart linker or a program database, an inline function must be defined in every translation unit in which it is used. Naturally, an implementation with a sufficiently smart compiler/linker can inline some functions without 'inline' help from the programmer. That's just an extra bonus. KLATCHKO: > > Hossein Moein (hmoein@jusdnews.fir.fbc.com) wrote: > > : I think it was a mistake to make `inline' a part of the C++ language. > > : Any comments !? MCADAMS: "S. McAdams" > Because some people are still obsessed with the idea of getting > performance from tight code rather than smart algorithms and the > language is fat enough that they think every little bit helps? > > Because then you can't set breakpoints on the inlined code (since only > god knows where all instances of it are)? > > Frankly I have no idea why anyone would have actually wanted to do it, > but there must have been a reason, if nothing more than "it seemed like > a good idea at the time". -steve BJARNE: Sometimes a function call is expensive - and this has nothing to do with how "fat" you might think the language is (and it isn't). Inlining critical operations can mean factors in performance. Modern machine architectures with pipelines, large register banks, vectorization, etc., sometimes make inlining more critical than it used to be. One old example is that UNIX I/O performance doubled when they inlined the most basic character I/O operations - inlining is often essential in inner loops of I/O and numerical computations. An newer example is the C++ standard library sort() running 7 times faster than the C standard library qsort() on a test of 500,000 elements because the C++ version inlined the comparison. The algorithms were equivalent. Trying to squeeze every last cycle out of every piece of code isn't a good idea; gaining factors in performance where people wait for response is. Sometimes better algorithms or better program structure is the answer, and sometimes better algoritms and better program structucture is affordable only because of inlining. 'inline' was a good idea. It still is.