Hacker News Reader

Comment by coliveira | Hacker News Reader

Completely agree. Despite what gurus say, there is hardly an advantage in writing const correct code, other than complying with existing libraries. Const is a nice concept in theory, but it doesn't provide any guarantees, since it is so easy to cast const away from any pointer. As a result, compilers can't do anything in practice with const, other than give an endless stream of compilation errors.

View on HN

I've actually just looked at the standard and there is a clear example something like this:

  int x;
  int const *cpx = &x;
  int *px = const_cast<int *>(cpx);
  *px = 1; // defined behavior, modifying non-const object through non-const pointer

While this may seem ok here, consider that the same applies to functions taking pointers to const. While this usually means the function won't modify the pointed-to objects, there is no guarantee from the language about that.

const_cast = code smell mutable = code smell

Pretty much anything that breaks the contract is readily apparent when reading/searching the code, and indicates that something needs to be rewritten.

Just because you can break the contract doesn't mean you should break the contract. Const correctness produces more readable/easily understood code.

Don't be lazy, and make life better for anyone that has to maintain and use the code after you.

Often, the point of stuff like 'const' is exactly to give a stream of compilation errors, because they presumably mean the programmer is doing something wrong (either using the const keyword wrong, or using the things marked const incorrectly)

Even if things like 'const' are useless to the compiler in optimisation terms, they provide (weak) contracts for the humans writing the code, and obvious flags when these contracts are broken, by having to be explicit about, in this instance, const_cast's. ('git grep const_cast' => places to examine closely for bugs.)

The problem is that const is also flawed as a contract. Whenever you're using const, you're trying to design a class that behaves as a mutable or as an immutable object, depending on how the pointer/reference is declared. A class that behaves in two different ways depending on the situation is a recipe for disaster, and that's exactly what const asks us to do.

I only noticed this problem when I learned how languages such as Smalltalk/objective-c deal with the same issue: they create different classes for each situation, so if you want a mutable array you have to say so.

Reply on news.ycombinator.com