I think this way of looking at it old. Even if the const-ness is somehow subverted without generating an error then most compilers (or at least GCC and Clang) will presume the code is compliant and make optimizations following what the standard allows. This potentially results in undefined behavior when that pointer you mentioned is used to modified a thing that ought to be const.
Jason Turner, the presenter, is writing code a few lines at a time and cross compiling for the Commodore 64. He shows his assembly at many steps of the way and shows how many functions are completely elided when const (and later constexpr) are used correctly.
There are a ton of other good talks from CppCon 2016 including one about const and what optimizations it makes possible and several about how compilers are more willing to "break" code that is non-compliant by making its behavior undefined. None of it really shocking or new, unless you have been writing to one compiler implementation instead of to the standard.
> None of it really shocking or new, unless you have been
> writing to one compiler implementation instead of to
> the standard.
I think you should focus more on giving concrete examples instead of making snide comments.
And, I'm not going to watch an eighty minute video in order to find out what you are talking about. Specific examples would be appreciated.
I agree that tagging globals as const can help the optimizer. If that is what you were talking about then I have no disagreement. However I have seen many people who expect speed wins when they tag member functions as const, or local variables as const. In those cases it is rare for 'const' to improve code-gen.
I was not attempting to be snide or rude. You are free to take the very concrete example I provided or not. You cannot say I didn't provide any.
The instant where the const keyword removes 95+% of the generated machine code is just after 28:00, but you should watch from at least a few minutes before that to establish context. That wasn't a global he put it on, but it wasn't a member variable either.
I recommend watching the whole talk, because the whole thing is pertinent to what optimizing can and cannot do. Because the speaker wants to get modern software onto an old machine he works around tight constraints while getting all of C++17. If you choose not to ignore something that you have expressed an interest in and is pertinent then you are doing something far worse than being rude and you are doing it to yourself.
Go benchmark you code, I have benchmarked mine. Putting const everywhere applicable helps even back in the pre-C++11 days. I state again not trusting and working with your optimizing compiler is simply an old an outmoded way of thinking.
Consider the amount of optimizations seen in the video from CppCon 2016: https://www.youtube.com/watch?v=zBkNBP00wJE
Jason Turner, the presenter, is writing code a few lines at a time and cross compiling for the Commodore 64. He shows his assembly at many steps of the way and shows how many functions are completely elided when const (and later constexpr) are used correctly.
There are a ton of other good talks from CppCon 2016 including one about const and what optimizations it makes possible and several about how compilers are more willing to "break" code that is non-compliant by making its behavior undefined. None of it really shocking or new, unless you have been writing to one compiler implementation instead of to the standard.