I think in general it does something for symbols visible outside the compilation unit (globals, public fields). Otherwise, the compiler usually has enough information to decide if something is actually a constant regardless of the const modifier.
`const` only does something for (global, static, local) variable declarations. The rest is just guidance to for the programmer. It doesn't do anything on pointers, and I think it doesn't do anything on members, but not entirely sure on the last one.
Yes, but it’s with the caveat that (like C++) const does not mean that the whole value is constant. It doesn’t even really mean any part of the value is constant necessarily, just that the symbol cannot be reassigned.
I don’t know that it eliminates that many questions, but it does eliminate one question, which is whether that variable will be reassigned. Arguably that doesn’t tell you very much.
> In my experience the compiler is pretty good at figuring out what is constant so adding const is more documentation for humans,
In the same TU, sure. But across TU boundaries the compiler really can't figure out what should be const and what should not, so `const` in parameter or return values allows the compiler to tell the human "You are attempting to make a modification to a value that some other TU put into RO memory.", or issue similar diagnostics.
Actually, with the exception of the modest benefits from moving globals to the read-only data segment it is rare to get optimization benefits from tagging something as const.
const is for enforcing correctness by the compiler. It tells the compiler about intent, but it doesn't give the compiler any extra information that it can use for optimizing.
Example: If you mark a member function as const then the compiler knows that you can't modify member variables. However the compiler won't use that to optimize the function - what it will use is its own data flow analysis that independently shows that you aren't modifying any member variables.
The distinction becomes important if you call some non-member function whose definition is not visible. At that point the compiler has to assume that that function might modify the object, though a separate cached pointer. So, the fact that the member function is const becomes useless as soon as the the compiler can't analyze code flow anymore.
Const doesn't actually help compilers (at least in C/C++ based languages). Since it can be const_cast away and still work in a standards compliant way, any optimisation assuming const values never change is a bug. Instead the compiler will use other techniques, e.g. finding variables that are only written to on initialisation, and those don't even need to be marked const.
Author here. I'm a big believer in adding const everywhere - local variables, globals, member functions, etc.
Marking globals as const can move them to the read-only segment which has some modest performance improvements, but in most other cases const doesn't affect code-gen at all. Using const prevents programmers from doing certain things, and the compiler enforces that. That suggests that the compiler already knows whether or not programmers are doing those things - it doesn't need a 'const' hint to tell it. And in those cases where it can't tell, the 'const' hint is usually not sufficient for it to depend on.
In short, with the exception of moving globals to the read-only segment I am not aware of any performance improvements from using const.
> It allows more sensible code and compiler optimizations.
Unfortunately no, const only tells the compiler optimizer something when applied to variables but not for reference or pointer types (or member functions, where it just means apply const to the this pointer). It would be nice if there were a stronger co_const that would tell the compiler could assume is never cast away (or at least that the variable is not modified through that pointer/reference even if the const is cast away) but C++ const is not that.
In my experience the compiler is pretty good at figuring out what is constant so adding const is more documentation for humans, especially in C++, where const is more of a hint than a hard boundary. Devirtualization, as can happen when you add a final, or the optimizations enabled by adding a restrict to a pointer, are on the other hand often essential for performance in hot code.
C/C++ const has no effect on optimization, unless it's on a global/static object and the compiler can see the original declaration.
I'm not going to look it up in the C++ spec, but in C it's only undefined behavior if the original object was const, and it would make sense for C++ to be the same.
Adding const to globals is useful on most or all compilers. It deserves mention in C/C++ FAQs as a best practice. You can see this for yourself with simple test apps using gcc and clang.
The C++ standard doesn't mandate this, but good toolchains do put constant data in a separate read-only segment.
When the compiler can assume your values don't change magically, it can optimize their use.
This is true for restricted pointers, for global-scope variables which can only be accessed in the same translation unit, for stuff in inlined functions (often), etc.
--------------------------------------------
const is a bit shifty. const makes the compiler restrict what it allows you to write, but it can still not really assume other functions don't break constness via casting:
void i_can_change_x_yeah_i_can_just_watch_me(const int* x)
{
*(int*) x = x + 1;
}
now, if the compiler sees the code, then fine (maybe), but when all you see is:
In languages with a compilation step, this is true but a side effect. Really, what "const" denotes is an association between a name and a value (ie a binding, in this case an assignment, although there are other kinds of binding such as naming positional arguments in a function signature) which has to be performed when the name is declared, and which cannot be changed once made. (Hence for example in Javascript why properties of an unsealed object can still be modified even via a const binding - what's immutable isn't the value, but the association of that value with the const-declared name.)
It's not even that: it's that if it sees a pointer declared const, it doesn't know if it was actually defined const.
I may have a non-const object that I pass to a function that takes it by const pointer: that doesn't magically make it const! The object can still be modified, e.g., by an opaque function in the caller which modifies the object not necessarily by casting away cost, but because the object isn't const at all (e.g., it may have a non-const reference to the object).
Const definitely helps optimizations, but only when the object is actually cost. References or pointers to const objects can't tell you that.
reply