inline

"inline" means that the compiler puts it inline if it can. "static inline" would relieve the compiler from the need to export the function, so if it's not used outside of the file where it's declared then it won't get compiled as a separate function ("static inline" sounds like a good idea, come to think of it).

"extern inline" is something of a contradiction in terms; unless it has been given special meaning by ANSI I would take it as doing nothing or generating a warning.

I got some info as below from GNU C - "Inline Functions In C". (Refer :

Sometimes it is necessary for the compiler to emit a stand-alone copy of the object code for a function even though it is an inline function

- for instance if it is necessary to take the address of the function, or if it can't be inlined in some particular context, or (perhaps) if optimization has been turned off. (And of course, if you use a compiler that doesn't understand "inline", you'll need a stand-alone copy of the object code so that all the calls actually work at all.)

There are various ways to define inline functions; any given kind of definition might definitely emit stand-alone object code, definitely not stand-alone emit object code, or only emit stand-alone object code if it is known to be needed.

extern inline function definition - Stand-alone object code is never emitted. normal inline function definition - Stand-alone object code is always emitted static inline function defintion - Stand-alone object code may be emitted if required.

But still, At which practical scenario we need either of these ?

Where will be the practical use/application of these ( 'static inline function' or 'extern inline function' or 'normal inline function' ) ?

Thx in advans, Karthik Balaguru

pro: speed. cpu doesn't execute a call/return or push/pop instructions. In cached systems the inline code is already in the cache.

con: size. you duplicate the inline code as many times as you use the "function", thus, bigger.

Bob

cached systems the inline code is already

"function", thus, bigger.

Most compilers are smart about inlining and only use inline as a hint, so large inline functions, or medium sized ones that are called frequently are not inlined. Similarly small functions that are not marked inline may be inlined automatically. In C++ such smart inlining significantly improves codesize compared to always inlining or never inlining.

Back to the original question: use static inline when the function is defined in a C file and static. Use inline when the function is defined in a header. Don't use GCC's broken extern inline as it won't work, isn't portable and not compatible with either C99 or C++.

Wilco

"extern inline" definitions never generate stand-alone code, and they have global linkage. That means that in normal use (i.e., calling the inlined function) you get inlined code. If an out-lined version is needed, such as if you take the function's address or compile with no optimisation, then you get a normal extern function call. You need to have an extra copy of the definition without the "extern" (you can also omit the "inline") in some module, to generate the actual out-lined code.

This version is good if your function will often be used both inlined and outlined. The gcc documentation generally recommends it (though I believe that is changing now).

Because the code is always emitted, you can't use the definition in a header file. But you can use a normal "extern" declaration in the header, and an "inline" definition in the code, and the inlined version will be used within that one module, and the outlined version will be used from other modules.

This version is of little practical use - modern compilers will automatically inline code in a module if it is appropriate, so you gain very little.

This is the arrangement I use regularly. You can put your "static inline" functions in header files, and all modules can use them safely. If (and only if) an outlined version is needed, it will be generated automatically. But if an outlined version is needed in two modules, then each module will get its own copy (unlike "extern inline").

There are potential complications if you have static local variables in inlined functions, which can quickly get confusing. It's best to think of "static inline" as being a safer and more powerful type of macro, and avoid static locals (though ordinary locals are no problem).

mvh.,

David

cached systems the inline code is already

"function", thus, bigger.

Actually, compilers will also happily inline large functions automatically - if they are only ever called once. That's one of the several advantages in using "static" unless a function really needs to be global.

I think it's better to use "static inline" in both cases. Obviously if a function is defined in a C file, and only ever used in that module, then it should be "static" anyway. But I think "static inline" makes sense in headers too - you don't risk generating extra code unless the function can't be inlined for some reason (and gcc can warn you about that if you want), whereas with a plain "inline" you will get extra code. The only complication I can see is if you need static locals in the inlined function.

Agreed. "extern inline" makes some sense if the same function is often used inline, and often used outline - but that's such a rare combination that you're better off making two separate functions.

... snip ...

It is totally ridiculous to use 'static' in a header file. The purpose of headers is to export connections to the C file. static components are not exportable.

cached systems the inline code is already

"function", thus, bigger.

if they are only ever called once.

really needs to be global.

It's generally a bad idea to inline large functions, even if they are static and only called once. Apart from there being little gain possible in such cases, register allocators work better on smaller functions with low register pressure, so inlining big functions often results in worse code. There are techniques that can reduce this effect, but they basically involve splitting off regions with high register pressure and independently allocating each region. Not inlining calls to large functions gives you this for free.

function is defined in a C file, and only

"static inline" makes sense in headers too -

some reason (and gcc can warn you about

only complication I can see is if you

The problem is that if you use static inline in a header is that you may end up with multiple out-of-line copies of the same function (and the behaviour is like you wrote several independent copies rather than a single function called from multiple places). For really small functions it doesn't really matter as you'd expect them to be always inlined anyway.

In C99 you're pretty much forced to use static inline in headers, but in C++ it's better to use plain inline. I'm not sure why you think this generates extra code

- the idea of it is precisely to only emit an out-of-line copy when required (so no compilation resources are wasted), and if there are multiple copies they must all be shared (so codesize is as small as possible).

Wilco

cached systems the inline code is already

"function", thus, bigger.

if they are only ever called once.

really needs to be global.

and

I'm inclined to leave the details of that to the compiler writers - if they think that their register allocators will have problems when working on very large functions, then they would not use automatic inlining on single-use large functions. gcc has dozens of command-line options for fine-tuning and testing this sort of thing (presumably so do other compilers, although they may be limited to internal builds) - I expect their automatic testing to give them reasonable values to balance the size of the combined functions with other factors (code size and speed, and compile-time memory usage and speed). For example, on cpus with large numbers of registers, such automatic inlining can make a big difference as the overhead for calling big functions will be more significant (pushing and popping more registers), whereas for register-poor cpus it makes little difference. I don't expect it to be perfect, of course - "optimisation" is a misnomer.

function is defined in a C file, and only

"static inline" makes sense in headers too -

some reason (and gcc can warn you about

The only complication I can see is if you

like

You will only get multiple out-of-line copies if you use the static inline functions in a non-inlinable fashion (such as taking their address, or disabling inlining for debugging). As long as you don't force the compiler to generate the outlined copy, no such copies will be generated. If you find that your function is often used inline and outline, then you are probably better of re-structuring it into two versions of the functions.

it's

code -

no

all

That's because C++ "inline" is not exactly the same as C99 "inline" (to my understanding - which may be wrong, of course), and I was talking about C "inline" rather than C++. When C++ was developed, there were subtle changes to some of the default linkages so that a plain "inline" worked in an ideal fashion (as you described) - plain "const" data is similar. But when C copied the "inline" qualifier, it could not change the linkage defaults without changing the language (since "inline" is merely a hint in C, rather than a language feature) - thus you end up with "static inline". So for C++, plain "inline" is perhaps best while "static inline" is best for C (or for headers that are used by both languages).

No, the purpose of header files is to provide other modules with everything they need in order to use the corresponding C file - "extern" declarations are only part of that. Appropriate typedefs, constants, macros, comments, and other bits and pieces also have to be there. Of course, it would be much nicer if there were no need to have inline function definitions inside a header file, but unfortunately C (and C++) are designed for header files to contain all the information the compiler needs to use the module, rather than just all the information the programmer needs. "static inline" functions are thus a compromise between generating optimal code at the expense of ugly headers. If you are using a compiler that does good whole-program optimisation, you could replace the "static inline" with standard function declarations.

You are misusing 'static'. When applied to something at the base level, such as a 'global' variable, it says that that variable is not to be visible outside the file. Similarly when applied to a function. When applied to a variable defined within a function, it also says that variable is to reside in static storage, and not be visible outside that function.

As far as the general purpose of headers, I don't think you are disagreeing. The only things exported are values, names, types etc. such that they can be used in other C files. C++ is a different language, and I am not speaking about that.

Static also does one other important thing - it lets the compiler know that since the object in question does not have external linkage, then it knows everything about how the object is used. The compiler can use this information to "cheat" if it wants - for example, it could use alternative calling conventions if that makes better code, it could remove unused static data, and it knows if a static function is only used once it can usefully be inlined even if it is big.

It is this feature of "static" that is important in using "static inline" for macro-type functions. Since the function is inlined in all its uses in the translation unit, the compiler does not need to generate an outlined version - as it is declared "static", the compiler knows it cannot be accessed from elsewhere, and can therefore safely be dropped. If it turns out that an outlined version *is* needed, then it can be generated at the time. If outlined versions are needed in different translation units, then you will get multiple copies (each with local static linkage) - this is of little disadvantage, because your "static inline" functions will (should!) almost always be inlined, and are normally small and of little cost if they *do* get outlined.

Yes, I think we mostly agree on the purpose of headers (I was just expanding on your description to make it a bit more general). But in C (and C++ - it's a different language, but suffers even more from the same problem) you can't avoid having a certain amount of implementation in the header file, especially if the size and speed of the code is important.

mvh.,

David