information hiding vs. inlining

[copx]

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.

[santosh]

copx wrote:

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.

[Walter Banks]

santosh wrote:

> 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?
> >
>

> 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.

Walter..

[Keith Thompson]

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]

"copx" <co...@gazeta.pl> schrieb im Newsbeitrag news:g4ntom$975$1...@inews.gazeta.pl...

> Do compilers inline functions even if the programmer could not do
> it manually because the needed information is hidden at the language level?

[snip]

Thanks everyone!

[Stephen Sprunk]

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.

S