I know for a function this simple it will be inlined:
int foo(int a, int b){
return a + b;
}
But my question is, can't the compiler just auto-detect that this is the same as:
int foo(const int a, const int b){
return a + b;
}
And since that could be detected, why would I need to type const anywhere? I know that the inline keyword has become obsolete because of compiler advances. Isn't it time that const do the same?
Yes, the compiler can prove constness in your example.
No, it would be of no use :-).
Update: Herb Sutter dedicated one of his gotchas to the topic (http://www.gotw.ca/gotw/081.htm). Summary:
The article is, of course, worth reading.
With respect to whole program optimization/translation which usually is necessary to exploit constness cf. the comments below from amdn and Angew.
const could benefit code, Herb Sutter concludes with: "Even when it comes to optimization, const is still principally useful as a tool that lets human class designers better implement handcrafted optimizations, and less so as a tag for omniscient compilers to automatically generate better code." –
Horta You don't put const as the result of not modifying a variable. You use const to enforce you not modifying it. Without const, you are allowed to modify the value. With const, the compiler will complain.
It's a matter of semantics. If the value should not be mutable, then use const, and the compiler will enforce that intention.
const is also proof that it can make the same optimizations whether or not you specified const. I would guess that most compilers will thus generate exactly the same code for specified const and non-specified-const-but-not-modified-anyway. –
Alderson inline the compiler will inline functions at its discretion whether or not we ask it to. I'm saying the same for const. I never declare functions inline anymore cause the compiler knows better than I do anyway. Why would I declare variables const? –
Horta const for the reason I said. Even if const-related optimizations happen whether or not you specify const, there are still other, better reasons to specify it. The primary reason to specify const is your intention, like I said in my answer. If you MEAN const, then specify const. –
Alderson const causes instruction overhead for the compiler? –
Chivalrous Yes, the compiler can prove constness in your example.
No, it would be of no use :-).
Update: Herb Sutter dedicated one of his gotchas to the topic (http://www.gotw.ca/gotw/081.htm). Summary:
The article is, of course, worth reading.
With respect to whole program optimization/translation which usually is necessary to exploit constness cf. the comments below from amdn and Angew.
const could benefit code, Herb Sutter concludes with: "Even when it comes to optimization, const is still principally useful as a tool that lets human class designers better implement handcrafted optimizations, and less so as a tag for omniscient compilers to automatically generate better code." –
Horta can't the compiler just auto-detect that this is the same as...
If by that you mean whether the compiler can detect that the variables are not modified in the second case, most likely yes. The compiler is likely to produce the same output for both code samples. However, const might help the compiler in more complex situations. But the most important point is that it keeps you from inadvertently modifying one of the variables.
const? I realized that you modified that with, "complex situations." So maybe it's too difficult to identify such an occurrence, I was just hoping to see something first-hand. –
Horta The compiler will always know what you did and will infer internal constness from that in order to optimize the code.
What the compiler can never know is what you wanted to do.
If you wanted a variable to remain constant but accidentally change it later in the code the compiler can only trap this error if you tell the compiler what you wanted.
This is what the const keyword is for.
struct bar {
const int* x;
};
bar make_bar(const int& x){
return {&x};
}
std::map<int,bar> data;
shuffle(data);
knowing that bar will never modify x (or cause it to be modified) in its lifetime requires understanding every use of bar in the program, or, say, making x a pointer to const.
Even with perfect whole program optimization (which cannot exist: turing machines are not perfectly understandable), dynamic linking means you cannot know at compile time how data will be used. const is a promise, and breaking that promise (in certain contexts) can be UB. The compiler can use that UB to optimize in ways that ignores the promise being broken.
inline is not obsolete: it means the same thing it ever did, that linker collisions of this symbol are to be ignored, and it mildly suggests injecting the code into the calling scope.
const simplifies certain optimizations (which may make them possible), and enforces things on the programmer (which helps the programmer), and can change what code means (const overloading).
Maybe he could but the const statement is also for you. If you set a variable as const and try to assign a new value afterwards you will get an error. If the compiler would make a var out of it by himself this would not work.
Const qualifier is a method to enforce behavior of the variables inside your scope. It only provides the compiler the means to scream at you if you try to modify them inside the scope where they are declared const.
A variable might be truly const (meaning it is writen in a read only location, hence compiler optimizations) if it's const at the time of it's declaration.
You can provide your 2nd function non const variables who will become "const" inside the function scope.
Or alternativelly you can bypass the const by casting , so the compiler cannot parse your whole code in an attempt to figure out if the valuea will be changed or not inside the function scope.
Considering that const qualifiers are mainly for code enforcing, and that compilers will generate the same code in 99% of cases if a variable is const or non const, then NO, the compiler shouldn't auto-detect constness.
auto. If the code is going to end up the same, then how is const helping anything? Why do we write it at all? –
Horta Short answer: because not all problems are that simple.
Longer answer: You cannot assume that an approach which works with a simple problem also works with a complex problem
Exact answer: const is an intent. The main goal of const is to prevent you doing anything accidentially. If the compiler would add const automatically it would just see that the approach is NOT const and leave it at it. Using the const keyword will raise an error instead.
© 2022 - 2024 — McMap. All rights reserved.
constis to prevent future you to mistakenly modify a value. When reading a long function, if you seeconst int xat the start, you know that at line 300xis still the same even without checking the previous code. – Rangedconstfor the compiler so much as you type it for yourself. You are telling the compiler to kick you if you ever try to change its value. – Uroscopyaandbare not assigned to and non-volatile, thus that they are effectivelyconst, and act accordingly.constis far more powerful when it is applied to pointers, or is part of a function's interface (its signature), since then a compiler can rely on the promises of the function to optimize. – Unmentionableinlineis far from obsolete. It allows for multiple definitions of the function to exist in the program without violating ODR. – Harryharshinline, it is a request that the compiler is allowed to ignore: the compiler might inline-expand some, all, or none of the places where you call a function designated asinline." Do you disagree with that? – Hortainlinekeyword, which does more than just this ignorable request for inlining. – Harryharshinlinebeing used in reference to functions/methods. – Hortaconst. – Hortaconstexists. – Hodgesinlinenot being a ignored? Doesn't the compiler do the exact same thing withinlined and non-inlined functions? – Hortainline, and include that header in more than one source file, you'll get a linker error. You will not get that error if you do mark it asinline. – Harryharshint f() { return 42; } int main() { return f(); }. File2:int f() { return 42; }. Both linked into the executable. – Harryharshinlinesolve that? I'm definitely seeing an error there whether or not you useinline. – Hortafs asinline, it must link correctly. That is the semantics of theinlinekeyword, and "inline functions" in C++. It allows the function to be defined in more than one translation unit (such as when you include a header with its definition). – Harryharshinlinea necessary keyword. I've opened a question here: https://mcmap.net/q/234810/-is-there-still-a-use-for-inline-duplicate/2642059 I want to understand what you're saying, I was hoping that given the ability to answer rather than comment you could convert me to aninlinedisciple. – Horta