Is there stack associated when a executing an inline function?

M

Mahesh

Hi,
I need to know if stack frames are generated in case of a
inline function execution or
do they execute just like macros?
if they execute like macros, then what is the need for having
inline function?
where would you use macros and where inlines?

Thanks
Mahesh
 
R

Richard Bos

Mahesh said:
I need to know if stack frames are generated in case of a
inline function execution or do they execute just like macros?

There is no definite answer to that question, so you will have to read
the documentation for your implementation. Be prepared to find that the
answer may be "no, it is neither the same as a normal function nor as a
normal macro".

Richard
 
S

santosh

Mahesh said:
Hi,
I need to know if stack frames are generated in case of a
inline function execution or do they execute just like macros?

Normally, when a function's code is inlined, stack frames won't be
generated. The purpose of inlining is to avoid the costs associated
with a machine level function call and it's supporting code.
if they execute like macros, then what is the need for having
inline function?

One major advantage (and sometimes a major disadvantage) is the type
checking you get with inline functions. Macros are simply text
substitution and as such the later phases of the compiler aren't even
aware of their existence.
where would you use macros and where inlines?

Inline is just a hint to the compiler, which it is free to ignore.
Therefore if you need to be *sure* that the code must be duplicated at
each call site, then use macros. Also macros are necessary when you
want to simulate a crude form of generic code like C++'s templates.

One more fact to note is that the *inline* keyword is new to C99, which
has not been fully implemented by many C compilers. You can work around
this by testing the __STDC_VERSION__ macro and defining *inline* to
nothing if the former is less than 199901L. But very old compilers may
not define this macro at all, so be warned.
 
J

jacob navia

Mahesh said:
Hi,
I need to know if stack frames are generated in case of a
inline function execution or
do they execute just like macros?

A stack <frame> will not be generated but any local
storage that the inline function uses will be added to
the local storage of the calling function.

void inline fn(int n)
{
char[1024*64];
// ...
}

That will add 64K to the local storage of all functions that use
the inline function, IF the compiler decides to inline the
function. Note that a compiler can decide not to inline anything.
(For instance it can decide to not inline when the debug
option is ON)

if they execute like macros, then what is the need for having
inline function?

Because parameter passing is safer, since all normal checks
are done. Besides, you are sure that the parameters are
evaluated once only.
where would you use macros and where inlines?

Macros can be handy in places where precisely you do NOT want
the checks done with inline functions, and you want a textual
substitution.
 
R

Richard Tobin

if they execute like macros, then what is the need for having
inline function?
[/QUOTE]
One major advantage (and sometimes a major disadvantage) is the type
checking you get with inline functions.

You generally don't lose type checking with macros, because the
expansion gets type checked in the usual way. If getc is a macro and
you call it with something that isn't a FILE *, you'll probably
get a bunch of fatal, if unclear, errors.

The more compelling reason for inline functions is that you can't
use arbitrary constructs in macros that are used in expressions.
C's macros are just powerful enough to let you write getc and putc,
but anything that needs declarations or a loop can't be done.

-- Richard
 
M

Morris Dovey

Kenny said:
Be aware that use of the word "stack" in this ng (even if the subject is
pancakes), by non-Clique members, will result in flamage.

Good point - many newbies are unaware that not all machine
architectures include a stack mechanism.

Flames are generally reserved for intellectually conceited types
who present ignorance as virtue.
 
K

Kenny McCormack

Hi,
I need to know if stack frames are generated in case of a
inline function execution or
do they execute just like macros?
if they execute like macros, then what is the need for having
inline function?
where would you use macros and where inlines?

Thanks
Mahesh

Be aware that use of the word "stack" in this ng (even if the subject is
pancakes), by non-Clique members, will result in flamage.
 
K

Kenny McCormack

Good point - many newbies are unaware that not all machine
architectures include a stack mechanism.

Wow! Can you say 'goosestepping' ?
Flames are generally reserved for intellectually conceited types
who present ignorance as virtue.

More goosestepping.
 
M

Morris Dovey

Kenny said:
Wow! Can you say 'goosestepping' ?


More goosestepping.

Heh! If you find /me/ that kind of threatening, you must be a
delicate flower indeed. Those of the group who've actually met me
are, without a doubt, laughing their socks off.

Your defensive attitude leaves somewhat to be desired, but you do
have considerable entertainment value.

:-D
 
K

Keith Thompson

jacob navia said:
A stack <frame> will not be generated but any local
storage that the inline function uses will be added to
the local storage of the calling function.

How do you know? Can you cite the standard to support this claim?

The implementation you describe is certainly plausible, but the
standard says nothing about stack frames, either for inline functions
or for ordinary functions. See C99 6.7.4. To the original poster: a
recent draft of the C99 standard can be downloaded in PDF format from
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>.

Briefly, the standard imposes some restrictions on inline functions,
but otherwise says only that they behave like ordinary functions.

[snip]
 
J

jacob navia

Keith said:
How do you know? Can you cite the standard to support this claim?

Yes. See the definition of local variables and local storage...
The implementation you describe is certainly plausible, but the
standard says nothing about stack frames, either for inline functions
or for ordinary functions.

6.2.4.4
An object whose identifier is declared with no linkage and without the
storage-class specifier static has automatic storage duration

Normally, objects with automatic storage duration are implemented
in the stack. Of course, regulars do not accept the fact that 99%
of all machines around use a stack but I really do not care.
 
M

Micah Cowan

jacob navia said:
Yes. See the definition of local variables and local storage...

6.2.4.4
An object whose identifier is declared with no linkage and without the
storage-class specifier static has automatic storage duration

Normally, objects with automatic storage duration are implemented
in the stack. Of course, regulars do not accept the fact that 99%
of all machines around use a stack but I really do not care.

None of which goes even close to validating your assertion that a
stack frame will _not_ be generated.
 
P

Paul Hsieh

       I need to know if stack frames are generated in case of a
inline function execution or do they execute just like macros?

The implicit call stack retains all its behaviors as normal regardless
of function call decorations like "inline".

The only thing the standard can say about "inline" is that it prevents
an function's address be stored in a function pointer. For many
cases, this can already be established by the compiler, but this is
useful for compilers that don't. (Its essentially, a new keyword,
helpful for old compilers that will not be updated to the new
standard. Don't ask me; I had no hand in this.)
      if they execute like macros, then what is the need for having
inline function?

macros just perform text substitutions, and cannot call themselves
recursively.
where would you use macros and where inlines?

You use macros to avoid call overhead and when text substitution is
sufficient. Macros also have certain compile-time capabilities that
you don't get from function calls: stringification with # x and text
concatenation via: x ## y.
 
J

jacob navia

Micah said:
None of which goes even close to validating your assertion that a
stack frame will _not_ be generated.

A "stack frame" consists of a pushed former stack frame pointer,
and a new stack frame pointer that it is hold in a dedicated register

This is done in all functions at function startup modulo some weird
systems that use other methods; have no stack; run in a coffee
machine that has no hardware stack pointer or in the famous DS9.

It would be completely weird that in an inline procedure the compiler
would save the current stack pointer and establish a new stack
frame since there is no function call.

Of course you can say now (like all "regulars" do in similar situations

"Weird but not impossible!"

And I would have to say

YES. It is not impossible that a compiler establishes 53765
stack frames and then pops 53765 stack frames after the inlined
function call.

Otherwise I would like to know a compiler that generates a
stack frame without generating a function call. Please give me
a single example.

OK?
 
K

Kaz Kylheku

Hi,
       I need to know if stack frames are generated in case of a
inline function execution or
do they execute just like macros?
      if they execute like macros, then what is the need for having
inline function?
where would you use macros and where inlines?

Inline functions provide the same semantics as real functions:
argument conversions, type checking, automatic referential hygiene,
single evaluation of argument values, and a body with declarations and
multiple returns. Macros don't even ensure that a substituted
expression maintains its integrity with respect to surrounding
operators, which may have a higher precedence than that expression's
principal operator.

A lot of the features of an inline function can be emulated in a macro
if you have the GNU C extension that a { } block in parentheses can be
used as an expression, and combine that with a number of conventions.
That's not ANSI C, so you're out of luck.

Even if you have the GNU C extension ({ .. }), there still the hygiene
problem. What does that mean? Suppose that your macro expansion has to
call some helper functions, foo and bar. And it has to refer to a
global variable called xyzzy:

{
// body of inline function
if (xyzzy) foo() else bar();
}

If this is done as a macro, then you have the lexical capture
problem: the place where the macro is inserted can have its own local
xyzzy variable.


{
int xyzzy = 0;
void (*foo)(void) = &some_function;

MACRO();
}

Now the expansion of the macro refers to the local xyzzy, not the
global one. And when it calls function foo, it's actually calling
through the local pointer here.

This scoping problem doesn't occur with inline functions, which have
their own independent scope just like normal functions.

In C++ you can overcome this problem by using namespaces, and by using
fully-qualified namespace identifiers in your macro expansions. In C,
you have to make sure that your macros refer to some names that are
unlikely to be used elsewhere. That's yet one more convention to
follow in making a nearly bullet-proof macro.
 
K

Kaz Kylheku

Yes. See the definition of local variables and local storage...


6.2.4.4
An object whose identifier is declared with no linkage and without the
storage-class specifier static has automatic storage duration

Normally, objects with automatic storage duration are implemented
in the stack. Of course, regulars do not accept the fact that 99%
of all machines around use a stack but I really do not care.

Automatic objects are associated with blocks, not function bodies.

There is no requirement that all of the blocks within a function body
must be allocated in a single piece of automatic storage which is
acquired on entry into the function and deallocated on exit. (An
inlined function can be considered to be a block for this purpose).

In principle, blocks can allocate and deallocate individually. That
requires a small overhead, but it would be a smart implementation
strategy for blocks that contain large arrays. Or at least a code-
generation option, if not default behavior.
 
J

jacob navia

Kaz said:
In principle, blocks can allocate and deallocate individually. That
requires a small overhead, but it would be a smart implementation
strategy for blocks that contain large arrays. Or at least a code-
generation option, if not default behavior.

Care to name a SINGLE compiler system that does this kind of stuff?
 
K

Kaz Kylheku

It would be completely weird that in an inline procedure the compiler
would save the current stack pointer and establish a new stack
frame since there is no function call.

However, it wouldn't be weird at all if the inlined procedure simply
moves the stack pointer by some delta to enlarge the current frame,
then references all of its locals with respect to the current frame,
and then moves the stack pointer back by the same delta upon
termination to release the storage.
 
M

Morris Dovey

Richard said:
But what would be the point?

It'd allow re-use of that memory by another (subsequent) inlined
procedure or function call. Waste not, want not.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,007
Latest member
obedient dusk

Latest Threads

Top