What's wrong with const?

Question

What are the known shortfalls of const in C++ and C++0x?

Answer 1

One thing that is "wrong" is that you cannot convert T** to T const * const * which should be allowed because it is not dangerous. Not allowing T** to convert to T const ** is correct, that conversion is not valid.

I have sometimes mentioned that const actually is a cheap way to "split" your interface into read-only methods and write methods. It would probably be impractical in C++. It would be more practical in Java to have ReadOnly versions of collections though, where they don't have const and where their collection types are more object-orientated.

const-ness does not propagate: The issue here is that if I pImpl my class, the constness is not "checked" by the compiler, i.e. my interface class can have a "const" method call a non-const method on the pImpl and the compiler won't complain. That is because the only thing my const method is guaranteed not to do is change the pointer to point to a different object, and my pImpl is never going to change. It could even be a const pointer (not pointer to const).

The lack of proper co-variance between shared_ptr<T> and shared_ptr<const T> might be an issue too, although in general I have seen that not to be the problem, but that developers usually typedef their shared_ptrs and rarely typedef the shared_ptr to const. And they will sometimes pass const shared_ptr<T> & and think that they are passing a shared pointer to a const T (as with const T*) which they are not.

Answer 2

One thing is that it is still possible subvert it. i.e. it is still legal to do something like this:

void foo(const inst& x)
{
   const_cast<int&> x = 3;
}

You can even use things like memset to subvert it without an explicit const_cast.

This is a trade-off between having the compiler enforce const and allowing some flexibility for non const aware interfaces.

Which leads to another limitation, in that it has not been universally embraced, which is in part due to another problem, which is that using const is an all-or-nothing proposition. If you start using it, you will need to propagate it throughout your code base.

Answer 3

The main problem is that you have to write it. It should be the default, and all mutable variables or parameters should be specified explicitly.

Answer 4

Another problem that has not been mentioned yet is the possibility for a badly designed interface to subvert const (even in the absence of casts).

Example:

class TreeNode {
public:
    TreeNode& getParent() const { return *parent_; }
    TreeNode& getLeft()   const { return *left_;   }
    TreeNode& getRight()  const { return *right_;  }
private:
    //TreeNode has a pointer to the Tree to enable navigation of the tree.
    //Assume that other design constraints mean that this must be a pointer 
    //rather than a reference.
    TreeNode* parent_;
    TreeNode* left_;
    TreeNode* right_;
};
//This function demonstrates the ability for const to be subverted.
TreeNode& remove_const(TreeNode const& toRemoveConstFrom) {
    TreeNode& parent(toRemoveConstFrom.getParent());
    TreeNode& leftChild(parent.getLeft());
    TreeNode& rightChild(parent.getRight());
    return &toRemoveConstFrom == &leftChild ? leftChild : rightChild;
}

The intransitive nature of const means that it is possible to have an interface where a non-const reference to an object can be obtained from a const reference to an object. This is something to be careful of when designing interfaces.

Answer 5

"issues"?

If you aren't going to be modifying the value of a passed pointer (it is used purely for pass-by-reference input to a function), mark it is const. Ditto if the value of a particular variable will not change after its initialization. If a function is safe to call on a const class instance, mark it const too. The more items are correctly annotated const, the less likely you are to inadvertently make a mistake and the more optimizations the compiler will be theoretically able to perform in the absence of complete knowledge (such as when compiling with only function prototypes available).

Modern versions of gcc have support for warning when you try to cast a const variable to a non-const one. I suggest you leave those warnings enabled.

The only thing to watch out for is exactly what you are marking const; const char * foo() is not the same as char * foo() const.

Answer 6

The only thing wrong with const is that it is seriously underrated by to many developers. It's one of the best tools in C++'s toolbox, very sharp, and yet not dangerous to cut yourself with.