Some years ago i'd agree, but experience has shown that C/C++ compiler writers would rather win benchmark games than keep working code working. So it'd be nice if there was a better reason than "well, a lot of code would break if they did that".
Some years ago i'd agree, but experience has shown that C/C++ compiler writers would rather win benchmark games than keep working code working. So it'd be nice if there was a better reason than "well, a lot of code would break if they did that".
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.