Who`s Afraid to Be Const Correct? Take Your Object`s Bits Literally - Make Your Interface Conceptually Const.

(Page 4 of 5 )

We are going to extend the class and provide a function that transforms the label into uppercase.

void LabelToUpper() ;

The question I have now is whether or not this should be a constant member function. Since the function won’t make any bitwise changes to our class (the address in pointer m_pLabel remains untouched), we can guarantee this to the user by making the function const, right?

Not really. This is where you have to stick to the concept of const and think about how the class will be perceived by the user. Even though none of the data members are changed in a bitwise manner, the contents of the class have changed in a conceptual way. Therefore don’t declare the function as const, because it will only confuse matters!

Aliasing Problem

Take a look at the following function:

void foo(int const &a, int &b) {

 int temp=a;

 ++b;

 assert(a==temp);

}

Is it possible to trigger the assert? Surely because ‘a’ is declared const, it will always equal ‘temp’?

Actually, there is an exception:

int value = 42;

foo(value, value);

Now both ‘a’ and ‘b’ reference the same variable, and it is perfectly legal to make changes to this variable through the ‘b’ reference. This is also known as the aliasing problem, and it applies in the same manner to pointers.

Although the problem is very clear when stated this way, things can get pretty obfuscated when the function with the aliasing problem is nested deep inside the call stack and defined in another source file. It may even be part of a library for which you don’t have the source code!

Next: Const and Mutable >>
 

More C++ Articles
More By J. Nakamura

Comments On: Who`s Afraid to Be Const Correct? Take Your Object`s Bits Literally

>>> Be the FIRST to comment on this article!