CS 1124 — Object Oriented Programming

Common C++ Programming Errors

Some of these errors will cause compilation errors. Some may compile but result in linking errors. Some will compile and link but cause errors while running. And some, you may get away with completely, but are just dumb things to do and will probably bite you another time.

• Misuse of the Include Guard.
  A common mistake is to use same symbol in multiple files for #ifndef. Check out the Include Guard notes.
• const
  • Failing to mark parameters or methods as const when they ought to be.
  • Marking a member function const in the class definition but not in the member function implementation.
• Returning a value in a void function. Or forgetting how to return from a void function.
• Confusing the name of an array with the contents of the first element.
• Leaving off the semi-colon after a class definition. The resulting compilation error messages are confusing.
• Default parameters. Assigning the default in a prototype and a definition.
• Forgetting to put the parentheses when calling a method that doesn't have any arguments:
  cout << aDwarf.getName << endl;
  instead of:
  cout << aDwarf.getName() << endl;

Design Issues

Students often have trouble getting their code to work, not because they have trouble with C++, but because they have trouble breaking a problem into pieces that make sense. This applies nearly as much to students who generally do well in the course as it does to those who struggle.

The general problem comes down to, "Can you say in a few words what the purpose of a section of code is?" The simpler your description, then the more likely your code actually does what you wanted.

• Ill-defined functions.
  Possibly the most common problem is writing a function whose purpose is hard to define. Keep the purpose of your function clear.
• Confusing "finding" and "doing".
  Often you need to loop through some data structure in order to find a single element that you want to "do something" with. Students will often include the "do something" work inside the body of the loop. There's nothing wrong with this approach, except that it often makes the loop just complicated enough that even a good student then makes a mistake.
  Instead of writing something like:

  for (int i = 0; i < MAX; ++i) {
     // If we have found the target, do something with it
     // and finish.
     if (someTest(i)) {
        doSomething(i);
        break;  // or perhaps return
     }
  }

  try:

  int target = 0;
  // Find the target
  while (target < MAX && !someTest(target)) 
     ++target;
  // If we found it, do somthing with it.
  if (target < MAX) doSomething(target);

  Now your code is using the loop to find the target location. After finding it, we can do whatever is needed. Is one piece of code clearly better than the other? No. But getting the first approach to work correctly seems to be harder to do consistently.
  
  Of course, making the test and the task functions, as in someTest and doSomething above, makes the code easier to read and understand, too.

• Silly inefficiency.
  Think about what the nested loops below are doing. How should this have been coded?

  ifs >> name1 >> name2;
  for( int j = 0; j<people.size(); j++ ) {
      for( int k = 0; k<people.size(); k++ ) {
          if(name1 == people[j]->getName()) {
              if(name2 == people[k]->getName()) {
                  // if people with name1 and name2 exist in the vector of Person
                  // then make them to point to each other
                  people[j]->setSpouse( people[k] );
              }
          }
      }
  }

Home

Maintained by John Sterling (jsterling@poly.edu). Last updated January 23, 2011