can one switch off the implicit inline rule?
-
Hi, is there a way to switch off implicit inline, that is
class ClassOfImplementationNamespace
{
void itsFunc(int x)
{
// let the compiler alone decide
// whether to inline this code,
// it will know better
}
};should no more give a compiler hint automatically, to inline this. Something like a #pragma NoImplicitInline? Thank you, Werner
-
Hi, is there a way to switch off implicit inline, that is
class ClassOfImplementationNamespace
{
void itsFunc(int x)
{
// let the compiler alone decide
// whether to inline this code,
// it will know better
}
};should no more give a compiler hint automatically, to inline this. Something like a #pragma NoImplicitInline? Thank you, Werner
WernerP wrote:
Something like a #pragma NoImplicitInline?
You are possibly looking for auto_inline(off)[^].
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche .·´¯`·->Rajesh<-·´¯`·. [Microsoft MVP - Visual C++]
-
Hi, is there a way to switch off implicit inline, that is
class ClassOfImplementationNamespace
{
void itsFunc(int x)
{
// let the compiler alone decide
// whether to inline this code,
// it will know better
}
};should no more give a compiler hint automatically, to inline this. Something like a #pragma NoImplicitInline? Thank you, Werner
WernerP wrote:
is there a way to switch off implicit inline,
Such as the /Ob0 compiler switch? There's also
#pragma auto_inline(off)."Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
-
Hi, is there a way to switch off implicit inline, that is
class ClassOfImplementationNamespace
{
void itsFunc(int x)
{
// let the compiler alone decide
// whether to inline this code,
// it will know better
}
};should no more give a compiler hint automatically, to inline this. Something like a #pragma NoImplicitInline? Thank you, Werner
-
Hi, is there a way to switch off implicit inline, that is
class ClassOfImplementationNamespace
{
void itsFunc(int x)
{
// let the compiler alone decide
// whether to inline this code,
// it will know better
}
};should no more give a compiler hint automatically, to inline this. Something like a #pragma NoImplicitInline? Thank you, Werner
but the true question is : why would you do that ?
[VisualCalc][Binary Guide][CommDialogs] | [Forums Guidelines]
-
but the true question is : why would you do that ?
[VisualCalc][Binary Guide][CommDialogs] | [Forums Guidelines]
Perhaps he's a
C#(orJava) fan. :-DIf the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Thank you. I'm not quite certain, whether this is, what I want. What I definitely do not want is to prevent the compiler from inlining. I think it knows best. What I actually want is to switch that implicit "inline" off, which is automatically associated with the function, although you don't see it, and which is a sweettalk to the compiler to inline the function whatever might be best. Werner
-
but the true question is : why would you do that ?
[VisualCalc][Binary Guide][CommDialogs] | [Forums Guidelines]
Hi, Because dividing class function declaration from definition does make sense, if the interface is to be seen by other modules. If the interface is just for the imlementation namespace of a certain module, I would not even put it into a header. Why? Because I don't want to recompile other modules, if the private interface changes. And because splitting declaration from definition means more administration of code and higher cost. It's overhead, if I don't want to export the functions it declares to others. This I think is a common concern of software engineering, and does not have to do with loving either one programming language or the other. Look, C++ has been called a multiparadigmatic language by it's founder. It should make us free to implement whatever pattern makes sense to us. Werner
-
Thank you. I'm not quite certain, whether this is, what I want. What I definitely do not want is to prevent the compiler from inlining. I think it knows best. What I actually want is to switch that implicit "inline" off, which is automatically associated with the function, although you don't see it, and which is a sweettalk to the compiler to inline the function whatever might be best. Werner
WernerP wrote:
What I definitely do not want is to prevent the compiler from inlining. I think it knows best. .......... What I actually want is to switch that implicit "inline" off, which is automatically associated with the function, although you don't see it, and which is a sweettalk to the compiler to inline the function whatever might be best.
I find these two conditions to be contradictory. In the first you want the compiler to decide, but in the second you don't want it to be automatic.... :confused: :~ It's probably the compiler option "/Ob1" you want, but you should also have a look at what happens when you're using the keywords for inlining here[^].
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
Hi, Because dividing class function declaration from definition does make sense, if the interface is to be seen by other modules. If the interface is just for the imlementation namespace of a certain module, I would not even put it into a header. Why? Because I don't want to recompile other modules, if the private interface changes. And because splitting declaration from definition means more administration of code and higher cost. It's overhead, if I don't want to export the functions it declares to others. This I think is a common concern of software engineering, and does not have to do with loving either one programming language or the other. Look, C++ has been called a multiparadigmatic language by it's founder. It should make us free to implement whatever pattern makes sense to us. Werner
WernerP wrote:
This I think is a common concern of software engineering, and does not have to do with loving either one programming language or the other. Look, C++ has been called a multiparadigmatic language by it's founder. It should make us free to implement whatever pattern makes sense to us.
Consider why Tox asked the question he did (and that English is not his native tongue). It was not to belittle you, but more to find out if you actually knew what you were doing and why, or were just doing it because a friend's cousin's boss said it was the way to go. You'd be surprised at the number of questions we see here that should not be asked. That doesn't mean that the poster did not have a legitimate concern; it just means that they did not understand the problem first.
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
-
WernerP wrote:
This I think is a common concern of software engineering, and does not have to do with loving either one programming language or the other. Look, C++ has been called a multiparadigmatic language by it's founder. It should make us free to implement whatever pattern makes sense to us.
Consider why Tox asked the question he did (and that English is not his native tongue). It was not to belittle you, but more to find out if you actually knew what you were doing and why, or were just doing it because a friend's cousin's boss said it was the way to go. You'd be surprised at the number of questions we see here that should not be asked. That doesn't mean that the poster did not have a legitimate concern; it just means that they did not understand the problem first.
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
Well said David.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
WernerP wrote:
This I think is a common concern of software engineering, and does not have to do with loving either one programming language or the other. Look, C++ has been called a multiparadigmatic language by it's founder. It should make us free to implement whatever pattern makes sense to us.
Consider why Tox asked the question he did (and that English is not his native tongue). It was not to belittle you, but more to find out if you actually knew what you were doing and why, or were just doing it because a friend's cousin's boss said it was the way to go. You'd be surprised at the number of questions we see here that should not be asked. That doesn't mean that the poster did not have a legitimate concern; it just means that they did not understand the problem first.
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
-
WernerP wrote:
What I definitely do not want is to prevent the compiler from inlining. I think it knows best. .......... What I actually want is to switch that implicit "inline" off, which is automatically associated with the function, although you don't see it, and which is a sweettalk to the compiler to inline the function whatever might be best.
I find these two conditions to be contradictory. In the first you want the compiler to decide, but in the second you don't want it to be automatic.... :confused: :~ It's probably the compiler option "/Ob1" you want, but you should also have a look at what happens when you're using the keywords for inlining here[^].
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownRoger Stoltz wrote:
find these two conditions to be contradictory. In the first you want the compiler to decide, but in the second you don't want it to be automatic.... Confused Unsure
In the second I *want* it to be automatic. That's my point. The inline keyword, and I think implicit inline too, means, that you don't let the compiler be automatic but try to tell him what to do. This is what I *don't* want and would like to switch off. Regards Werner
-
Roger Stoltz wrote:
find these two conditions to be contradictory. In the first you want the compiler to decide, but in the second you don't want it to be automatic.... Confused Unsure
In the second I *want* it to be automatic. That's my point. The inline keyword, and I think implicit inline too, means, that you don't let the compiler be automatic but try to tell him what to do. This is what I *don't* want and would like to switch off. Regards Werner
WernerP wrote:
The inline keyword, and I think implicit inline too, means, that you don't let the compiler be automatic but try to tell him what to do.
Read the link I provided in my previous post and you will find that you cannot force the compiler to do inline expansion, not even with
__forceinline. The "implicit inline" your talking about must be the "/Ob2" compiler setting, thus if you're not compiling your code with that option, there won't be any "implicit inline"."It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
WernerP wrote:
The inline keyword, and I think implicit inline too, means, that you don't let the compiler be automatic but try to tell him what to do.
Read the link I provided in my previous post and you will find that you cannot force the compiler to do inline expansion, not even with
__forceinline. The "implicit inline" your talking about must be the "/Ob2" compiler setting, thus if you're not compiling your code with that option, there won't be any "implicit inline"."It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownI will do that. Thank you. Maybe I misunderstood the definition of implicit inline? I understood, that if a function is defined like that
class A
{
void someFunc()
{
// code
}
}this is equivalent to
inline void A::someFunc()
{
// code
}and I want it to be equivalent just to
void A::someFunc()
{
// code
}Best regards Werner
-
Roger Stoltz wrote:
find these two conditions to be contradictory. In the first you want the compiler to decide, but in the second you don't want it to be automatic.... Confused Unsure
In the second I *want* it to be automatic. That's my point. The inline keyword, and I think implicit inline too, means, that you don't let the compiler be automatic but try to tell him what to do. This is what I *don't* want and would like to switch off. Regards Werner
WernerP wrote:
The inline keyword, and I think implicit inline too, means, that you don't let the compiler be automatic but try to tell him what to do. This is what I *don't* want and would like to switch off.
Marking something as inline (while you think it would be beneficial) may turn out to be expensive too (well, with certain cases). So, the best way is to let the compiler do the dirty work for you. I am believing that I can never outsmart the compiler on making such a decision. With the default settings, the compiler won't inline any function automatically. BTW - Instead of the switch, the #pragma directive would give you greater flexibility on where to impose the restriction, in case you need it. [Added] BTW - if that is you who has low-voted this post of mine, please do let me know what is that you feel so bad about it. :)
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche .·´¯`·->Rajesh<-·´¯`·. [Microsoft MVP - Visual C++]
modified on Tuesday, October 14, 2008 11:29 AM
-
WernerP wrote:
The inline keyword, and I think implicit inline too, means, that you don't let the compiler be automatic but try to tell him what to do. This is what I *don't* want and would like to switch off.
Marking something as inline (while you think it would be beneficial) may turn out to be expensive too (well, with certain cases). So, the best way is to let the compiler do the dirty work for you. I am believing that I can never outsmart the compiler on making such a decision. With the default settings, the compiler won't inline any function automatically. BTW - Instead of the switch, the #pragma directive would give you greater flexibility on where to impose the restriction, in case you need it. [Added] BTW - if that is you who has low-voted this post of mine, please do let me know what is that you feel so bad about it. :)
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche .·´¯`·->Rajesh<-·´¯`·. [Microsoft MVP - Visual C++]
modified on Tuesday, October 14, 2008 11:29 AM
-
Dear Rajesh, I am very sorry, this happened automatically because in Germany marks at school are like that 1 = best, 6 = worst. I still can't get rid of that. Thank you very much and best regards Werner
WernerP wrote:
I am very sorry, this happened automatically because in Germany marks at school are like that 1 = best, 6 = worst. I still can't get rid of that.
Thanks for the explanation. It is times like this when I realise CP is a truly global community. :)
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche .·´¯`·->Rajesh<-·´¯`·. [Microsoft MVP - Visual C++]