1 hour ago, 0r0d said:Well, when you specify something as "const", as with function input parameters, you're defining your contract with the user of that function. If you find yourself trying to modify something that's const, you either screwed up or the person who defined that API screwed up. Getting rid of the const is not the answer because that just hides the fact that there's some lazy programming going on. Now, it's true that if the laziness is pervasive throughout the codebase, then you will find yourself having to go around modifying a bunch of stuff... and some might be difficult because of said laziness in the coding. So, of course, it's up to you on how to proceed. My personal approach is to make sure the entire codebase is const-correct as I write it and the problem never arises. It's not hard, it's just a matter of thinking about what a function/variable does when you write it, and then declare it appropriately. If some assumption changes, then I change the API and everyone is happy. This pays off later in better code, fewer bugs or bugs caught earlier, and less headaches. You also give the compiler the option to generate more optimal code. It might not in most cases, but it could in certain specific situations.
More information on const correctness:
I never got in a situation where const helped me to make better code. I know what i want to modify and what i dont want to modify. In 20 years of programming i never got a single case, where the compiler helped me just because i tried to modify unmutable data.
But i had million errors using someones api which are based on const-correctness, getting it to work with my code base - creating a ton of useless friction.
I see const just as a way to differentiate between input and output parameters, but nothing more. Everything else is useless friction for me.
But i dont doubt that it may catch some bugs for lazy programmers and i agree that it makes api´s more clean.