Home arrow C++ arrow Page 4 - Who`s Afraid to Be Const Correct? Take Your Object`s Bits Literally

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

This is the second article in a tutorial series covering const correctness. In this article, Jun Nakamura discusses some problems concerned with bitwise copy construction and bitwise constness, how to make your interface conceptually const, and how to make changes to an object that are not visible to the user.

Author Info:
By: J. Nakamura
Rating: 5 stars5 stars5 stars5 stars5 stars / 7
August 23, 2005
  1. · Who`s Afraid to Be Const Correct? Take Your Object`s Bits Literally
  2. · Bitwise Copy Construction
  3. · Bitwise Constness
  4. · Make Your Interface Conceptually Const.
  5. · Const and Mutable

print this article

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 wont 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 dont 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;




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 dont have the source code!

blog comments powered by Disqus

- Intel Threading Building Blocks
- Threading Building Blocks with C++
- Video Memory Programming in Text Mode
- More Tricks to Gain Speed in Programming Con...
- Easy and Efficient Programming for Contests
- Preparing For Programming Contests
- Programming Contests: Why Bother?
- Polymorphism in C++
- Overview of Virtual Functions
- Inheritance in C++
- Extending the Basic Streams in C++
- Using Stringstreams in C++
- Custom Stream Manipulation in C++
- General Stream Manipulation in C++
- Serialize Your Class into Streams in C++

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2018 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials