Is there stack associated when a executing an inline function?

Discussion in 'C Programming' started by Mahesh, Feb 29, 2008.

  1. Mahesh

    Mahesh Guest

    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
    Mahesh, Feb 29, 2008
    #1
    1. Advertising

  2. Mahesh

    Richard Bos Guest

    Mahesh <> wrote:

    > 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
    Richard Bos, Feb 29, 2008
    #2
    1. Advertising

  3. Mahesh

    santosh Guest

    Mahesh wrote:

    > 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.
    santosh, Feb 29, 2008
    #3
  4. Mahesh

    jacob navia Guest

    Mahesh wrote:
    > 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.

    > Thanks
    > Mahesh



    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Feb 29, 2008
    #4
  5. In article <fq8jmu$j4j$>,
    santosh <> wrote:

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


    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
    --
    :wq
    Richard Tobin, Feb 29, 2008
    #5
  6. Mahesh

    Morris Dovey Guest

    Kenny McCormack wrote:

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

    --
    Morris Dovey
    DeSoto Solar
    DeSoto, Iowa USA
    http://www.iedu.com/DeSoto
    Morris Dovey, Feb 29, 2008
    #6
  7. In article <>,
    Mahesh <> wrote:
    >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.
    Kenny McCormack, Feb 29, 2008
    #7
  8. In article <>,
    Morris Dovey <> wrote:
    >Kenny McCormack wrote:
    >
    >> 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.


    Wow! Can you say 'goosestepping' ?

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


    More goosestepping.
    Kenny McCormack, Feb 29, 2008
    #8
  9. Mahesh

    Morris Dovey Guest

    Kenny McCormack wrote:
    >
    > In article <>,
    > Morris Dovey <> wrote:
    > >Kenny McCormack wrote:
    > >
    > >> 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.

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

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

    --
    Morris Dovey
    DeSoto Solar
    DeSoto, Iowa USA
    http://www.iedu.com/DeSoto
    Morris Dovey, Feb 29, 2008
    #9
  10. jacob navia <> writes:
    > Mahesh wrote:
    >> 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.


    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]

    --
    Keith Thompson (The_Other_Keith) <>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Feb 29, 2008
    #10
  11. Mahesh

    jacob navia Guest

    Keith Thompson wrote:
    > jacob navia <> writes:
    >> Mahesh wrote:
    >>> 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.

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


    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Feb 29, 2008
    #11
  12. Mahesh

    Micah Cowan Guest

    jacob navia <> writes:

    > Keith Thompson wrote:
    >> jacob navia <> writes:
    >>> Mahesh wrote:
    >>>> 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.

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


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

    --
    Micah J. Cowan
    Programmer, musician, typesetting enthusiast, gamer...
    http://micah.cowan.name/
    Micah Cowan, Feb 29, 2008
    #12
  13. Mahesh

    Paul Hsieh Guest

    On Feb 28, 11:37 pm, Mahesh <> wrote:
    >        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.

    --
    Paul Hsieh
    http://www.pobox.com/~qed/
    http://bstring.sf.net/
    Paul Hsieh, Feb 29, 2008
    #13
  14. Mahesh

    jacob navia Guest

    Micah Cowan wrote:
    > jacob navia <> writes:
    >
    >> Keith Thompson wrote:
    >>> jacob navia <> writes:
    >>>> Mahesh wrote:
    >>>>> 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.
    >>> 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.

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

    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Feb 29, 2008
    #14
  15. Mahesh

    Default User Guest

    Morris Dovey wrote:

    > Kenny McCormack wrote:


    > > More goosestepping.


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


    Come on. Troll, feed, please, don't.





    Brian
    Default User, Feb 29, 2008
    #15
  16. Mahesh

    Kaz Kylheku Guest

    On Feb 28, 11:37 pm, Mahesh <> wrote:
    > 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.
    Kaz Kylheku, Feb 29, 2008
    #16
  17. Mahesh

    Kaz Kylheku Guest

    On Feb 29, 10:29 am, jacob navia <> wrote:
    > Keith Thompson wrote:
    > > jacob navia <> writes:
    > >> Mahesh wrote:
    > >>>        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.

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


    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.
    Kaz Kylheku, Feb 29, 2008
    #17
  18. Mahesh

    jacob navia Guest

    Kaz Kylheku wrote:
    > 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?


    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Feb 29, 2008
    #18
  19. Mahesh

    Kaz Kylheku Guest

    On Feb 29, 11:08 am, jacob navia <> wrote:
    > 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.
    Kaz Kylheku, Feb 29, 2008
    #19
  20. Mahesh

    Morris Dovey Guest

    Richard Tobin wrote:
    >
    > In article <>,
    > Kaz Kylheku <> wrote:
    >
    > >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.

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

    --
    Morris Dovey
    DeSoto Solar
    DeSoto, Iowa USA
    http://www.iedu.com/DeSoto/Projects/Monitor/
    Morris Dovey, Feb 29, 2008
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Nish
    Replies:
    4
    Views:
    474
    Thomas Stegen
    Oct 8, 2004
  2. TGOS
    Replies:
    3
    Views:
    365
    Kevin Bracey
    Feb 28, 2005
  3. Ajay
    Replies:
    5
    Views:
    369
    Pete Becker
    Apr 1, 2006
  4. Replies:
    7
    Views:
    419
  5. Vinayak
    Replies:
    2
    Views:
    89
    Vinayak
    Jul 21, 2006
Loading...

Share This Page