About
Exploring Solution Spaces, Keith Ray's blog on Software development and other topics.

Send comments to:
keithray@mac.com

For Agile Training, eLearning, or Coaching contact:

Industrial Logic, Inc.

866-540-8336 (toll free)

510-540-8336 (Berkeley, California)

Links

xpminifaq

Résumé

“Adopting XP” Article 2002 (pdf)

“ Refactoring” Article 2006

AYE Conference

Lucien W. Dupont

Elisabeth Hendrickson

Johanna Rothman's Managing Product Development

Brian Marick's Exploration Through Example

Esther Derby's Insights You Can Use

Laurent Bossavit's Incipient(thoughts)

Dale Emery's Conversations with Dale

Martin Fowler's Bliki

Creating Passionate Users

Archives

Subscribe
RSS Exploring Solution Spaces XML

Const Assurance in C++

"splogs" is inspired to use 'const' more in C++ after exposure to Haskell. Quote:

[...] When a software developer is debugging a program (as s/he often is), just knowing that one "thing" will not change after creation decreases the scope of required knowledge for that session by one. If all things are immutable, that significantly reduces the probability that bugs are present in dynamic logic. Thus, by being "const-ipated" with your code (by using const wherever possible), you can kill bugs before they even appear!

An anonymous commenter responded:

I've found that striving for immutability in class design (also rubbing off from the functional versions where data types are immutable) also makes concurrency a lot easier and faster. For infrequently mutation, reconstructing parts of the object graph (to preserve immutability) can be a lot cheaper in the long run if it obviates the need for a lock in hot code paths.

Consider this bit of code:

Results aFunction(SomeClass& anObject)
{
    someval = anObject.SomeMethod();
    // later...
    someotherval = anObject.SomeOtherMethod();
    // etc.
    return results;
}

Given that anObject is not const, you'd have to assume that SomeMethod and SomeOtherMethod could be modifying the state of the object. If you changed the order of calls, or called one of those methods more than once, you could break the desired behavior. The only way to know for sure would be to look at the source-code and/or documentation for SomeClass's methods. Now with const-ness:

Results aFunction(const SomeClass& anObject)
{
    someval = anObject.SomeMethod();
    // later...
    someotherval = anObject.SomeOtherMethod();
    // etc.
    return results;
}

The simple act of declaring anObject to be const also implies that SomeMethod and SomeOtherMethod are const methods. (The compiler will complain if that's not true). This assumes the programmer for SomeClass was following the rules (that is, he's not 'faking' const-ness) and SomeClass isn't modifying some external state that we care about. In this case with a const reference and const methods, we could be pretty sure that we could change the order of method calls, and the number of times the methods are called, with no effect on the correct behavior.

Unfortunately, even with 'const' we can't always be sure the behavior is correct, so writing micro-tests helps enforce the intended behavior. A test like...

TEST(aFunctionDoesWhatWeWant)
{
    SomeClass anObject; // set up how we want
    Results fResults = aFunction(anObject);
    AssertEqual(expectedState, anObject.GetState());
    AssertEqual(expectedResults, fResults);
}

... would help us verify that the following changes are okay, if it still passes after changing the order and number of calls.

Results aFunction(const SomeClass& anObject)
{
    someval = anObject.SomeMethod();
    someotherval = anObject.SomeOtherMethod();
    // later...
    someotherval2 = anObject.SomeOtherMethod();
    someval2 = anObject.SomeMethod();
    // etc.
    return results;
}

Declaring a function parameter const also helps tell other programmers that the function isn't going to try to change the object's value. Tests will help document the function's desired behavior.

[/docs] permanent link