"Const-ness" in C++

In C++ you can declare class methods as

const

. The idea is that a

const

method does not change the value of instance' member variables (and doesn't call non-const methods on them).

The idea is nice, since it allows the compiler to detect a probably undesired changes to data. But as with almost every nice feature of C++, there are times when you need a way to circumvent it, because otherwise it prevents you from doing what you need.

Imagine, for example, a proprietary collection, which has a synchronized "get" operation. In the function it needs to lock some internal data structures to ensure data integrity and then returns the result. The problem is, that to lock using some C++ locking objects usually means breaking the

const

constraint, if the lock object is part of the instance.

Another example - consider using logging in your

const

methods - if the logger is part of the instance, then write operation (which is non-const by its nature) also violates the constness of the method.

That's where we see another C++ trick - to work around this problem there is something called

const_cast&lt;T&gt;

. This casting operator adds or removes "constness" to its argument. Isn't it pretty?

Another option is to use the

mutable

keyword (thanks to Steven for reminding me), when declaring the members which need to be changed inside

const

member functions.

The more I see things like that in conventional programming languages, the more I like functional programming languages, such as ML and Haskell. In their core they don't even have a notion of a "variable" - something that can change a value. All functions are

const

by definition - the state of the world is the same before the function call and after it, and only the return value matters.

Tags: computers

Categories: None |

5 comments have been posted.

July 1, 2011, 10:56 a.m. - Latrice ¶

You really saved my skin with this inofrmatoin. Thanks!

March 26, 2007, 11:24 p.m. - Steven ¶

A better solution to this problem is to use the mutable keyword. A mutable member of a const object can still be modified. The assumption is that a mutable member does not change the visible state of the object.

March 27, 2007, 7:39 a.m. - Andre ¶

You might be right from the syntax point of view, but think about optimization. If you mark a member variable as <code>mutable</code>, that would prevent the compiler from even try to optimize its usage. I think the keyword is more suitable for variables, which value comes from an external device.

March 27, 2007, 4:12 p.m. - Steven ¶

I think you have mutable confused with volatile, which is what you would use for variables who's value can change in unexpected ways that might trip up the compiler's optimizations. Mutable was added specifically to overcome the problem you described and has no effect on the compiler's optimization.

March 27, 2007, 7:22 p.m. - Andre ¶

You are probably right - shame on me :-)