copx wrote: > Do compilers inline functions even if the programmer could not do > it manually because the needed information is hidden at the language > level?
> I am talking about stuff like incomplete types and static variables > e.g.
> .. > get_attribute(object); > .. > Where object is an incomplete type in this unit and get_attribute > basically just does object->attribute.
> Or
> get_color(x);
> which should translate into Colors[x] but Colors[] is an array > declared static in another unit i.e. not accessible here at language > level.
The compiler could inline the functions if it had access to their source code. It cannot do so if they are in the form of libraries. Usually code to manage opaque data is already compiled and only public declarations are available in source form, so inlining may not be possible.
> > Do compilers inline functions even if the programmer could not do > > it manually because the needed information is hidden at the language > > level?
> The compiler could inline the functions if it had access to their source > code. It cannot do so if they are in the form of libraries. Usually > code to manage opaque data is already compiled and only public > declarations are available in source form, so inlining may not be > possible.
There are some compiler/linkers that make automated inline choices at link time that only need library objects. Most of the compilers that do full code optimization at link time have the ability to also inline library or application function objects without sources.
>> Do compilers inline functions even if the programmer could not do >> it manually because the needed information is hidden at the language >> level?
>> I am talking about stuff like incomplete types and static variables >> e.g.
>> .. >> get_attribute(object); >> .. >> Where object is an incomplete type in this unit and get_attribute >> basically just does object->attribute.
>> Or
>> get_color(x);
>> which should translate into Colors[x] but Colors[] is an array >> declared static in another unit i.e. not accessible here at language >> level.
> The compiler could inline the functions if it had access to their source > code. It cannot do so if they are in the form of libraries. Usually > code to manage opaque data is already compiled and only public > declarations are available in source form, so inlining may not be > possible.
Strictly speaking, the *compiler* can't do this kind of inlining even if it has access to the source code. It can't know that you won't change the source code and recompile it before linking.
For example, in a.c:
get_color(x);
and in b.c:
int get_color(int x) { static int Colors = { ... }; return Colors[x]; }
I can compile a.c, then completly change the implementation of get_color() and recompile b.c, then link. If the compiler has inlined the call in a.c, I get an inconsistent program.
This kind of fancy cross-unit inlining has to be done at the linking phase. This might re-invoke the compiler in some cases; if so, it does so at a time when you no longer have an opportunity to modify anything.
-- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"
copx wrote: > Do compilers inline functions even if the programmer could not do > it manually because the needed information is hidden at the language level?
> I am talking about stuff like incomplete types and static variables e.g.
> .. > get_attribute(object); > .. > Where object is an incomplete type in this unit and get_attribute basically > just does object->attribute.
> Or
> get_color(x);
> which should translate into Colors[x] but Colors[] is an array declared > static in another unit i.e. not accessible here at language level.
Some implementations are capable of doing that; it is allowed under the "as if" rule.
However, being able to inline (or do any other sort of optimization) across translation units (i.e. object files) is still in its infancy and not available with most implementations. If you want your accessor functions to be inlined with common systems today, you will need to provide a complete type and static inline accessor functions in your header file. Examine, for instance, your system's <stdio.h> for ideas on how to do this.
Note that using that strategy may cause significant versioning problems for you if you use <OT>dynamic libraries</OT> and aren't extremely careful.
