«

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

On Feb 28, 11:37*pm, Mahesh <mahesh1...@gmail.com> 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/

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

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

On Feb 28, 11:37*pm, Mahesh <mahesh1...@gmail.com> 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.

On Feb 29, 10:29*am, jacob navia <ja...@nospam.com> wrote:
> Keith Thompson wrote:
> > jacob navia <ja...@nospam.com> 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 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

On Feb 29, 11:08*am, jacob navia <ja...@nospam.com> 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.

Richard Tobin wrote:
>
> In article <12b8f0bd-7e79-486e-bdbf->,
> 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/