On Sun, 23 Jul 2006 17:46:11 GMT, jackklein@spamcop.net (Jack Klein)
wrote:

>Respecting the moderator's comment, the C++ standard says absolutely
>nothing about whether or not a compiler actually honors the request to
>expand a function's body in line.

It's also worth noticing that though from a declarative standpoint the
inline specifier applies to a function (function declaration) the
"inlining" process is relative to a function call, and the compiler
can (with good reasons) inline some of the calls and not others.

Importantly, inlining can be decided at increasingly wider contexts as
compiler technology progresses: it used to be established at the
translation unit level, but many implementations are now capable of
"link time code generation" (which implies they could even inline a
call to a function written in another language, for instance). And
there are profile directed optimizations: choose what and where to
inline based on instrumented runs. Managed environments and JIT
compilers go even further with "runtime inlining". All these
techniques progressively move the decision were more information exist
to decide. In light of this one might argue that the inline keyword is
more a solution to remove some of programmers' misplaced concerns than
a genuine technical tool.

--
Gennaro Prota

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article <h4oac2t1rnb5mmu91fiiso4sp4no7v95vr@4ax.com>, Gennaro Prota
<gennaro_prota@yahoo.com> writes
>All these
>techniques progressively move the decision were more information exist
>to decide. In light of this one might argue that the inline keyword is
>more a solution to remove some of programmers' misplaced concerns than
>a genuine technical tool.

Though originally motivated by the desire to make programmers feel more
comfortable with short functions (such as member functions that provide
access to the state of an object) its only 'semantic' value in C++ is in
allowing multiple (though identical) definitions across TUs.



--
Francis Glassborow      ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

===================================== MODERATOR'S COMMENT:

Let's keep replies on-topic: What the Standard says or should say about
function ininling.


===================================== END OF MODERATOR'S COMMENT
    It is well known that a function can be explicitly declared inline
using the keyword "inline". But the compiler doesn't make sure the
inline function is really inlined. For example, in the following code,
the function f is declared inline, but how can we judge whether the
compiler substitudes the function call with its implementation code, or
just give a function call
    I will be appreciative if anyone can give some suggestions.

Zhuo Hao
July 23rd,2006

The code is as follows:

#include<iostream>
using namespace std;

inline void f(){
 cout<<"Hello";
 cout<<" World!"<<endl;
}

int main(){


 f();

 return 1;
}


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Sun, 23 Jul 2006 08:53:03 CST, "hzhuo1@gmail.com"
<hzhuo1@gmail.com> wrote in comp.std.c++:

>
> ===================================== MODERATOR'S COMMENT:
>
> Let's keep replies on-topic: What the Standard says or should say about
> function ininling.
>
>
> ===================================== END OF MODERATOR'S COMMENT
>     It is well known that a function can be explicitly declared inline
> using the keyword "inline". But the compiler doesn't make sure the
> inline function is really inlined. For example, in the following code,
> the function f is declared inline, but how can we judge whether the
> compiler substitudes the function call with its implementation code, or
> just give a function call?
>     I will be appreciative if anyone can give some suggestions.
>
> Zhuo Hao
> July 23rd,2006
>
> The code is as follows:
>
> #include<iostream>
> using namespace std;
>
> inline void f(){
>  cout<<"Hello";
>  cout<<" World!"<<endl;
> }
>
> int main(){
>
>
>  f();
>
>  return 1;
> }

Respecting the moderator's comment, the C++ standard says absolutely
nothing about whether or not a compiler actually honors the request to
expand a function's body in line.  Some implementations have options
to emit some sort of message when they decide not to honor an inline
request.  This is a QOI issue, and if your compiler does not provide
such an option you might consider contacting the vendor or maintainers
and requesting one.

Something that one can do with any implementation is to examine the
generated output to see whether or not a function is actually inlined.
That, of course, is outside the scope of the language standard and is
implementation specific.

As to whether the standard should require a diagnostic from the
translator whenever it does not, or does, inline a function when
requested, I would be against it.  It could generate a lot of spurious
warnings.  But as a QOI issue, having the ability to turn such
messages on when desired, and off when not desired, is a nice feature.

In general, it only really matters if a completed, correct program
runs too slowly, and needs to be optimized.  In that case there are
tools, such as profilers, that can determine if non inlined functions
are a cause of the problem.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

hzhuo1@gmail.com wrote:
> ===================================== MODERATOR'S COMMENT:
> Let's keep replies on-topic: What the Standard says or should say about
> function ininling.
> ===================================== END OF MODERATOR'S COMMENT

The message that was posted was not about what the standard says or
should say; he was asking how he could find out how an compiler had
chosen to implement his code.  I don't see how a response to that
question could actually be responsive, and still be on-topic; this
implies that the question itself was off-topic, and therefore should
have bee rejected.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

kuyper@wizard.net wrote:
> hzhuo1@gmail.com wrote:
>> ===================================== MODERATOR'S COMMENT:
>> Let's keep replies on-topic: What the Standard says or should say about
>> function ininling.
>> ===================================== END OF MODERATOR'S COMMENT
>
> The message that was posted was not about what the standard says or
> should say; he was asking how he could find out how an compiler had
> chosen to implement his code.  I don't see how a response to that
> question could actually be responsive, and still be on-topic; this
> implies that the question itself was off-topic, and therefore should
> have bee rejected.

I believe that a response noting that the standard does not
address this, and possibly why, would be responsive and topical.
Jack Klein's post seems to illustrate this fairly well.  (I'm
not the moderator who approved the original question, but the
decision to approve seems reasonable to me.)

I do, however, agree that there's not much more that can
be said that is topical here.

-- James

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Jack Klein wrote:

> Respecting the moderator's comment, the C++ standard says absolutely
> nothing about whether or not a compiler actually honors the request to
> expand a function's body in line.  Some implementations have options
> to emit some sort of message when they decide not to honor an inline
> request.  This is a QOI issue, and if your compiler does not provide
> such an option you might consider contacting the vendor or maintainers
> and requesting one.
>
> Something that one can do with any implementation is to examine the
> generated output to see whether or not a function is actually inlined.
> That, of course, is outside the scope of the language standard and is
> implementation specific.
>
> As to whether the standard should require a diagnostic from the
> translator whenever it does not, or does, inline a function when
> requested, I would be against it.  It could generate a lot of spurious
> warnings.  But as a QOI issue, having the ability to turn such
> messages on when desired, and off when not desired, is a nice feature.
>
> In general, it only really matters if a completed, correct program
> runs too slowly, and needs to be optimized.  In that case there are
> tools, such as profilers, that can determine if non inlined functions
> are a cause of the problem.
>
Thanks for your advice. The standard says that it depends on the
compiler whether to do the inlining or not. I tested my code with
vc++8.0 and found it not inlined in debug mode but inlined in release
mode.

Zhuo Hao

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article <1153706861.514115.46520@75g2000cwc.googlegroups.com>,
"hzhuo1@gmail.com" <hzhuo1@gmail.com> writes
>Thanks for your advice. The standard says that it depends on the
>compiler whether to do the inlining or not. I tested my code with
>vc++8.0 and found it not inlined in debug mode but inlined in release
>mode.
Which is pretty normal because debugging with code inlined is pretty
tough on the tool chain.

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]