Re: -fobey-inline (was Re: gcc and inlining)

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

dewar at gnat dot com (Robert Dewar) writes:

| > That would be a disaster on STL-like code where function-object's
| > operator() are commonly defined in the enclosing class.  I can't see
| > any compeling reason why we should introduce that artificial distinction
| 
| I think there is an argument for a differentiation here. If a programmer
| specifies inline, I think the compiler should be more ready to inline it.

And if the programmer defines the function in the class, then the
compiler should inline it also.  Have a look at the C++ STL-like
codes out there.  Putting the threasold lesser than if the function
were explicitly marked inline won't help nobody.

A distinction from C here is that there is more than one ways in C++ to
say "inline".

| In my experience, the compiler does too much inlining at -O3, and often
| slows things down, so perhaps the automatic threshhold should be reduced,
| but I don't think that is a good reason for reducing the threshhold for
| an explicit inline. I am not ready to agree with people who think that
| inline must always be obeyed, but I do think the compiler should go to
| extra efforts to follow the (hopefully informed) hints from the user.

I agree with that.  But that is not an argument to ignore the inline
implied by in-class function definition:  That is part of common C++
styles of writing programs.

-- Gaby