«

Hi Everyone,

I have few questions on inline functions, when i declare a function as
inline, is it for sure that the compiler would replace the function
call with the actual body of the function? or is it a call taken by
compiler?

Second, i see that it is same as what Macro's used to do for c, if so
what is the advantage for going in for inline functions than to Macros?

wrote:
> I have few questions on inline functions, when i declare a function as
> inline, is it for sure that the compiler would replace the function
> call with the actual body of the function? or is it a call taken by
> compiler?

'inline' is a recommendation for the compiler. One thing it does for
sure is prevent breaking the ODR if the function is defined in more
than one TU.

> Second, i see that it is same as what Macro's used to do for c, if so
> what is the advantage for going in for inline functions than to
> Macros?

Many. Doesn't FAQ say anything about it?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

wrote:

> Hi Everyone,
>
> I have few questions on inline functions, when i declare a function as
> inline, is it for sure that the compiler would replace the function
> call with the actual body of the function? or is it a call taken by
> compiler?
>
> Second, i see that it is same as what Macro's used to do for c, if so
> what is the advantage for going in for inline functions than to Macros?

inline functions act a lot overloaded operators. You would declare an
inline function versus an overloaded operator for obvious reasons:
overloaded operators are symbol linked versus inline function style naming.
They do work the same, so you specifically probably should use these for
referencing variables through function like syntax or when calling a base
class function.

With MACROS, they are more or less aimed at single line expressions and not
really 2 or 3 though it is workable still.

Kevin Rouge <> writes:

> wrote:
>
> > Hi Everyone,
> >
> > I have few questions on inline functions, when i declare a function as
> > inline, is it for sure that the compiler would replace the function
> > call with the actual body of the function? or is it a call taken by
> > compiler?
> >
> > Second, i see that it is same as what Macro's used to do for c, if so
> > what is the advantage for going in for inline functions than to Macros?
>
> inline functions act a lot overloaded operators. You would declare an
> inline function versus an overloaded operator for obvious reasons:
> overloaded operators are symbol linked versus inline function style naming.
> They do work the same, so you specifically probably should use these for
> referencing variables through function like syntax or when calling a base
> class function.

??? This answer is partly nonsensical and, to the degree I can
understand it, entirely wrong. The notions of "inline functions"
and "overloaded operators" are orthogonal: "overloaded operators"
are just functions with odd names, and are inlined (or not) as you
choose. They are frequently inlined, but then many other sorts of
functions are also frequently inlined (e.g. simple getter / setter
methods).

To answer the OP's first question: read the FAQ
<http://www.parashift.com/c++-faq-lite/>, specifically section 9.
In a nutshell, the 'inline' keyword is only a hint to the compiler;
it may inline all calls to the function, only some, or none at all.
The compiler's behavior may be modifyable via switches; check your
compiler documentation for details.

For the second question....

> With MACROS, they are more or less aimed at single line expressions
> and not really 2 or 3 though it is workable still.

This is also wrong, or at least irrelevent; again, see the FAQ, IIRC
item 9.5. In C (_not_ C++) macros are used for many reasons, one of
which is to get the effect of an inline function: a chunk of code is
executed without the overhead of an actual function call. The
length of the macro is irrelevent.

However, using macros can be dangerous (again see the FAQ). Inline
functions were specifically introduced to provide the run-time
efficiency of macros, without all the other issues associated with
them.

Scott Meyers has an excellent discussion of the inline / macro issue
in "Effective C++", which all C++ programmers should read.

----------------------------------------------------------------------
Dave Steffen, Ph.D. Disobey this command!
Software Engineer IV - Douglas Hofstadter
Numerica Corporation
dg@steffen a@t numerica d@ot us (remove @'s to email me)

Dave Steffen wrote:

> Kevin Rouge <> writes:
>
>> wrote:
>>
>> > Hi Everyone,
>> >
>> > I have few questions on inline functions, when i declare a function as
>> > inline, is it for sure that the compiler would replace the function
>> > call with the actual body of the function? or is it a call taken by
>> > compiler?
>> >
>> > Second, i see that it is same as what Macro's used to do for c, if so
>> > what is the advantage for going in for inline functions than to Macros?
>>
>> inline functions act a lot overloaded operators. You would declare an
>> inline function versus an overloaded operator for obvious reasons:
>> overloaded operators are symbol linked versus inline function style
>> naming. They do work the same, so you specifically probably should use
>> these for referencing variables through function like syntax or when
>> calling a base class function.
>
> ??? This answer is partly nonsensical and, to the degree I can
> understand it, entirely wrong. The notions of "inline functions"
> and "overloaded operators" are orthogonal: "overloaded operators"
> are just functions with odd names, and are inlined (or not) as you
> choose. They are frequently inlined, but then many other sorts of
> functions are also frequently inlined (e.g. simple getter / setter
> methods).

I do not wish to debate with you. But your answer makes as little sense to
the degree I have in mind as the one I gave.

> To answer the OP's first question: read the FAQ
> <http://www.parashift.com/c++-faq-lite/>, specifically section 9.
> In a nutshell, the 'inline' keyword is only a hint to the compiler;
> it may inline all calls to the function, only some, or none at all.
> The compiler's behavior may be modifyable via switches; check your
> compiler documentation for details.
>
> For the second question....
>
>> With MACROS, they are more or less aimed at single line expressions
>> and not really 2 or 3 though it is workable still.
>
> This is also wrong, or at least irrelevent; again, see the FAQ, IIRC
> item 9.5. In C (_not_ C++) macros are used for many reasons, one of
> which is to get the effect of an inline function: a chunk of code is
> executed without the overhead of an actual function call. The
> length of the macro is irrelevent.
>
> However, using macros can be dangerous (again see the FAQ). Inline
> functions were specifically introduced to provide the run-time
> efficiency of macros, without all the other issues associated with
> them.
>
> Scott Meyers has an excellent discussion of the inline / macro issue
> in "Effective C++", which all C++ programmers should read.
>

You have not clarily giving your answer. I agree with you that you should
not use MACROs, but the question was not on principle but fact. If you can
prove a case or give an example, I will be intent on learning it.

> ----------------------------------------------------------------------
> Dave Steffen, Ph.D. Disobey this command!
> Software Engineer IV - Douglas Hofstadter
> Numerica Corporation
> dg@steffen a@t numerica d@ot us (remove @'s to email me)

>
> You have not clarily giving your answer. I agree with you that you should
> not use MACROs, but the question was not on principle but fact. If you can
> prove a case or give an example, I will be intent on learning it.

1. marcos are pre-processed at compile time... two problems here...
this may increase the size of your binary and if you get a compiled
time error in a macro you may have a hard time debugging the issues
since the macro really doesn not exist at runtime.

2. paramaters to macros are not type checked so, for example, you can
pass strings to a macro that does some integer arithmetic

3. Expressions passed into macros are not always evaluated before
entering the macro body. i.e.

#define MACRO (x) cout << "The value of x = " << x << endl;

int main ()
{
int x = 10;
MACRO (x++)

return 42; //
}

this would print out "The value of x = 10"

bjeremy wrote:
> [..]
> 3. Expressions passed into macros are not always evaluated before
> entering the macro body. i.e.
>
> #define MACRO (x) cout << "The value of x = " << x << endl;
>
> int main ()
> {
> int x = 10;
> MACRO (x++)

'x++' subexpression is evaluated at some point *before* the full
expression ('MACRO(x++)') is completely evaluated. What does "macro
body" have to do with all this?

>
> return 42; //
> }
>
> this would print out "The value of x = 10"

Uh.. So? If the 'MACRO' would be a function, how different would
the behaviour be?

void MACRO(int x) { cout << "The value of x = " << x << endl; }

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Kevin Rouge <> writes:

> Dave Steffen wrote:
>
> > Kevin Rouge <> writes:
> >
> >> wrote:
> >>
> >> > Hi Everyone,
> >> >
> >> > I have few questions on inline functions, when i declare a function as
> >> > inline, is it for sure that the compiler would replace the function
> >> > call with the actual body of the function? or is it a call taken by
> >> > compiler?
> >> >
> >> > Second, i see that it is same as what Macro's used to do for c, if so
> >> > what is the advantage for going in for inline functions than to Macros?
> >>
> >> inline functions act a lot overloaded operators. You would declare an
> >> inline function versus an overloaded operator for obvious reasons:
> >> overloaded operators are symbol linked versus inline function style
> >> naming. They do work the same, so you specifically probably should use
> >> these for referencing variables through function like syntax or when
> >> calling a base class function.
> >
> > ??? This answer is partly nonsensical and, to the degree I can
> > understand it, entirely wrong. The notions of "inline functions"
> > and "overloaded operators" are orthogonal: "overloaded operators"
> > are just functions with odd names, and are inlined (or not) as you
> > choose. They are frequently inlined, but then many other sorts of
> > functions are also frequently inlined (e.g. simple getter / setter
> > methods).
>
> I do not wish to debate with you. But your answer makes as little sense to
> the degree I have in mind as the one I gave.

Well, one problem is perhaps linguistic. "... makes as little sense
to the degree I have in mind ... " is very odd English, and like
several phrases in your earlier post, hard to make sense of.

For example, your statement

> inline functions act a lot overloaded operators

is not a meaningful English phrase. Assuming you left a word out,
and meant

> inline functions act a lot LIKE overloaded operators
^^^^

which _is_ a meaningful statement, it is also an incorrect
statement. Inlined functions act like inlined functions. Overloaded
operators act like overloaded operators. The two C++ notions
"inline function" and "overloaded operator" have nothing to do with
each other (that's what 'orthogonal' means). If your C++ books
don't make this clear, you need better books.

> > To answer the OP's first question: read the FAQ
> > <http://www.parashift.com/c++-faq-lite/>, specifically section 9.
> > In a nutshell, the 'inline' keyword is only a hint to the compiler;
> > it may inline all calls to the function, only some, or none at all.
> > The compiler's behavior may be modifyable via switches; check your
> > compiler documentation for details.
> >
> > For the second question....
> >
> >> With MACROS, they are more or less aimed at single line expressions
> >> and not really 2 or 3 though it is workable still.
> >
> > This is also wrong, or at least irrelevent; again, see the FAQ, IIRC
> > item 9.5. In C (_not_ C++) macros are used for many reasons, one of
> > which is to get the effect of an inline function: a chunk of code is
> > executed without the overhead of an actual function call. The
> > length of the macro is irrelevent.
> >
> > However, using macros can be dangerous (again see the FAQ). Inline
> > functions were specifically introduced to provide the run-time
> > efficiency of macros, without all the other issues associated with
> > them.
> >
> > Scott Meyers has an excellent discussion of the inline / macro issue
> > in "Effective C++", which all C++ programmers should read.
> >
>
> You have not clarily giving your answer. I agree with you that you should
> not use MACROs, but the question was not on principle but fact. If you can
> prove a case or give an example, I will be intent on learning it.

Again, maybe we're having linguistic problems: "clarily" is not a
word. But I think I know what you mean...

Your statement

> >> With MACROS, they are more or less aimed at single line
> >> expressions and not really 2 or 3 though it is workable still.

is incorrect. Macros are a preprocessor mechanism that are used in
many ways. Yes, one of them is to textually substitute short
expressions; there are many other uses, and it's incorrect to say
that macros are in any way aimed at such use.

In idiomatic C, macros are not restricted to short one-line
statements, and are frequently much longer.

In idiomatic C++, macros aren't used for short statements at all;
that's what inline functions are for.

Good C++ may use macros for much more complicated things; for
example, Eric Niebler's excellent (and mind-blowing) FOREACH macro
looks like this:


#define BOOST_FOREACH(VAR, COL) \
BOOST_FOREACH_DEFINE_RVALUE() \
if (boost::foreach_detail_::auto_any_t _foreach_col = BOOST_FOREACH_CONTAIN(COL)) {} else \
if (boost::foreach_detail_::auto_any_t _foreach_cur = BOOST_FOREACH_BEGIN(COL)) {} else \
if (boost::foreach_detail_::auto_any_t _foreach_end = BOOST_FOREACH_END(COL)) {} else \
for (bool _foreach_continue = true; \
_foreach_continue && !BOOST_FOREACH_DONE(COL); \
_foreach_continue ? BOOST_FOREACH_NEXT(COL) : BOOST_FOREACH_NOOP(COL)) \
if (boost::foreach_detail_::set_false(_foreach_contin ue)) {} else \
for (VAR = BOOST_FOREACH_DEREF(COL); !_foreach_continue; _foreach_continue = true)



... and Boost's preprocessor metaprogramming library has even more
mind-blowing examples.


----------------------------------------------------------------------
Dave Steffen, Ph.D. Disobey this command!
Software Engineer IV - Douglas Hofstadter
Numerica Corporation
dg@steffen a@t numerica d@ot us (remove @'s to email me)

Victor Bazarov wrote:
> bjeremy wrote:
> > [..]
> > 3. Expressions passed into macros are not always evaluated before
> > entering the macro body. i.e.
> >
> > #define MACRO (x) cout << "The value of x = " << x << endl;
> >
> > int main ()
> > {
> > int x = 10;
> > MACRO (x++)
>
> 'x++' subexpression is evaluated at some point *before* the full
> expression ('MACRO(x++)') is completely evaluated. What does "macro
> body" have to do with all this?
>
> >
> > return 42; //
> > }
> >
> > this would print out "The value of x = 10"
>
> Uh.. So? If the 'MACRO' would be a function, how different would
> the behaviour be?
>
> void MACRO(int x) { cout << "The value of x = " << x << endl; }
>
> V
> --
> Please remove capital 'A's when replying by e-mail
> I do not respond to top-posted replies, please don't ask

The increment will happen after the std::cout statment. This example
shows that macros sometimes do not behave intuitively in the presence
of side effects. If 100 developers were reading the code I bet you half
of them would expect that that "The value of x = 11" be printed out.
This would not happen in an inline function since the expression would
be evaluated before entering the function.

bjeremy wrote:
> Victor Bazarov wrote:
>> bjeremy wrote:
>>> [..]
>>> 3. Expressions passed into macros are not always evaluated before
>>> entering the macro body. i.e.
>>>
>>> #define MACRO (x) cout << "The value of x = " << x << endl;
>>>
>>> int main ()
>>> {
>>> int x = 10;
>>> MACRO (x++)
>>
>> 'x++' subexpression is evaluated at some point *before* the full
>> expression ('MACRO(x++)') is completely evaluated. What does "macro
>> body" have to do with all this?
>>
>>>
>>> return 42; //
>>> }
>>>
>>> this would print out "The value of x = 10"
>>
>> Uh.. So? If the 'MACRO' would be a function, how different would
>> the behaviour be?
>>
>> void MACRO(int x) { cout << "The value of x = " << x << endl; }
>>
>> V
>> --
>> Please remove capital 'A's when replying by e-mail
>> I do not respond to top-posted replies, please don't ask
>
> The increment will happen after the std::cout statment. This example
> shows that macros sometimes do not behave intuitively in the presence
> of side effects. If 100 developers were reading the code I bet you
> half of them would expect that that "The value of x = 11" be printed
> out. This would not happen in an inline function since the expression
> would be evaluated before entering the function.

Exactly *what* would not happen? Half of them would not expect? 10
would be printed? 11 would be printed? What's the difference in the
side effects of the macro versus the inline function? What is the
difference in the output? I have hard time seeing the point you're
trying to make.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask