This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: std::pow implementation
Gabriel Dos Reis wrote:
Please note that there is no "implicit" inline in C++. The only thing
that is present is that function definition within a class declaration
is an inline definition, because that is the orginal syntax before
inlining nonmember function was implemented. A function defined
within a class is as inline as a function defined with the "inline"
keyword outside a class.
I know; this is why I put "implicit" in quotes. But this doesn't help, I think.
Say I write the following
==========foo.h
class foo
{
inline void bar();
};
==========foo.cc
inline void foo::bar() {...}
No current g++ will inline foo::bar() (and most other compilers won't either) when I
call it from, say, baz.cc. So there is a practical difference between defining
a function in the class body, and declaring it as inline and defining it in a
separate .cc file.
If we assume for now that intermodule optimization is not done (and that's
the current situation), there is no way to tell the C++ compiler
"this function might be useful to inline", because it has to see the function
body before it can decide whether to inline it or not. And it can't see
it because it's in a different translation unit.
AFAIK, it's ill-formed to write
=========foo.h
class foo
{
void bar();
};
void foo::bar() {...}
=========end of foo.h
I think this is only OK if I explicitly declare bar() as inline.
If not, I run into trouble with the ODR.
| But this implies an "inline" directive
| which would more or less _force_ the compiler to always inline the code.
| So, if inline was as strict as you'd like to see it, there would be no
| way to tell gcc "here's a function that might be probably worthwhile to
| inline". I could only say "inline this" or "don't inline".
|
| This could change if gcc starts to inline functions across translation units,
| but currently it doesn't (I believe).
That "worthwhile inlining" could subject to higher optimiations
("-O3") if it is so that we've reached the level of sophistication
where automatic inline supersedes traditional "inline".
I'll be happy with this as soon as intermodule optimization works
well. Without it, we have not gained anything, as the example shows.
But I see on concrete real world codes that the "inline" meaning
transmutation GCC operates does cause more grief that it does good.
Probably. I just think it was caused by the fact that C++ compilers
have been imperfect (i.e. lacking intermodule inlining) for a long time.
And because so many codes exist that were written with the "transmuted"
meaning in mind, there will be a terrible lot of breakage if the meaning
is reset abruptly.
| You're right. It's not too beautiful and makes maintenance a bit harder,
| but on the other hand it shouldn't happen too often.
and is expressed with standard constructs.
Agreed. I was arguing for a possible extension of the standard itself, not
for introducing new pragmas.
Martin