| |||||||||||||
Drawing the line on inlineDrawing the line on inlinePosted Jan 6, 2006 16:42 UTC (Fri) by giraffedata (subscriber, #1954)Parent article: Drawing the line on inline Not mentioned in the article is one important and often overlooked fact about inlining: Inlining happens automatically. This is just about forced inlining. Even without the "inline" keyword, Gcc will inline a function if it looks beneficial. I think current versions have a way to explicitly exclude a function from inlining. So one really should use "inline" only where one has reason to believe he's smarter than Gcc, and forced inlining should always be respected. One other reason to use "inline" is where you use that warning option that warns you about unused functions. If you put a function in a header file, since not every file that includes the header file will use that function, you get that warning if you don't declare "inline".
(Log in to post comments)
Drawing the line on inline Posted Jan 13, 2006 8:13 UTC (Fri) by xoddam (subscriber, #2322) [Link] It used to be that no-one trusted compilers to do register allocationoptimally either, but now they do (admittedly there is a canonical algorithm for it, which AFAIK isn't the case for inlining) so the register keyword is vestigial. > Gcc will inline [any] function if it looks beneficial. Only if it's in the same compilation unit -- if there's only a prototype available, the compiler can see no code to inline. As things stand at the moment, only functions which developers think should be inlined are available in the API headers, and those are *all* marked with the inline keyword -- there'd be no point putting a function in a header if you didn't want it inlined. unit-at-a-time optimisation is an improvement, but it falls waaay short of whole-program optimisation. When that's available I'm sure no one will trust the compiler -- initially.
|
|||||||||||||