Apart from specifying to readers of the code that you may cause errors if you modify this variable(you can use comments to do this)
Not "may"; will cause errors in your program.
- A C++ compiler will enforce it with compilation failures and diagnostic messages ("compiler errors"), with no need for comments;
- A C compiler will enforce it for the most part, though its standard library has holes thanks to legacy, such as
strchr, and it has some rather lenient implicit conversion rules that can allow you to drop
constness without realising it quite easily. However, just because you got a successful compilation doesn't mean that you don't have errors; unfortunately, it does mean that the errors can be subtle bugs in your program, as well as big, spectacular crashes.
Either way, your program is guaranteed to contain an error inside it.
It seems to me that if you don't want a variable modified, simply don't.
Well that's all well and good, but nobody's perfect. Programmers make mistakes. This allows the compiler — which never makes mistakes (at least, not usually) — to point them out to you.
It's of particular use when you're using some data variable many, many lines of code away from where it was created. The further away it is, the easier it is to modify it without realising that you were not supposed to. For large, complex code bases it is simply a must.
You get a new measure of provability, correctness and stability in your code base, as well as a huge chunk off possible causes of really subtle and nasty bugs. There are also vast optimisation opportunities for your compiler (in some cases) when it knows that some value won't change after compilation.
We could list the advantages all day but, really, you won't fully grok it until you've worked on such a codebase.
In fact, in a perfect world, all variables would be
const by default, and you would need to declare them with the keyword
mutable to be able to change them. C++ is backwards.