I think it’s hard for us to implement a complicated algorithm, write down the code once, compile it, run, and get the expected result, in one shot. That rarely happens. Most of us will encounter some minor or major bugs in the code, and spend some time to find out what’s happening and debug. Programmer is a debugger, an old saying tells us.
Here is some common mistakes that are often found in C++ code. These are logical errors. That means the compiler will not tell us any errors (maybe warnings). Instead, we’re very likely to obtain unexpected result in resulting program. Remember–logical error is more severe than compile error!
Using uninitialized variables
C++ always gives default value of 0 to all global and static variables. But this rule doesn’t apply to local stack-based variables. Remember to initialize them!
int sum(int data[], int N)
{
int res; // should be `int res = 0;'.
for (int i = 0; i < N; i++)
res += data[i];
return res; // value of res is undefined.
}
= instead of ==
Almost all programmers have done this type of mistake. Yes, the operator= is different from operator==. The former is for assignment, and the latter is for equality testing. But don’t worry, if you use operator= for equality testing, most compilers will give you a descriptive warning.
bool is42(int x)
{
if (x = 42) // should be `if (x == 42)'.
return true;
else
return false;
// always returns true.
}
Array out of range
This type of error is usually hard to trace. C++ doesn’t perform any array bound checking, even at compile time. Assigning a location in array which is beyond its range, will overwrite other variable. Beware!
int data[2];
int victim = 0;
data[2] = 42;
printf("%d\n", victim);
// will print `42' to the screen!
Wrong counter variable in for loop
This is usually caused by copying and pasting a for loop for nesting. And the programmer forget to edit all the counter variable occurrences.
for (int i = 0; i < N; i++)
for (int j = 0; j < N; i++)
// will not work as expected.
Missing break statement inside switch
In C++ switch construct, the control of execution will continue to the next case label, if there’s no break or return statement. This is very different from Visual Basic. Make sure you have a break/return statement after each case label.
int x = 1;
switch (x)
{
case 1: puts("one");
case 2: puts("two");
case 3: puts("three");
}
// will print:
// one
// two
// three
Lack of braces in if statement
This can lead to a confusing else-part ownership. Example:
int number = 20;
if (number%2 == 0)
if (number > 30)
puts("even, high");
else
puts("odd");
// will print `odd' to the screen.
Note that the else clause belongs to the second if clause (precisely, to the nearest if). The compiler will ignore any indentation. A workaround is to surround the statements in the first if with braces.
int number = 20;
if (number%2 == 0)
{
if (number > 30)
puts("even, high");
}
else
puts("odd");
// nothing will be printed.
Extra unnecessary semicolons
Take a look to the following snippet.
for (int i = 0; i < 10; i++);
printf("*");
This will print only ONE asterisk. What is being repeated 10 times? The empty statement. Notice that there is one semicolon after the for construct.
Do you have other common mistakes to share?
Enjoyed this article? Subscribe to our RSS feed for free!
Related posts:
2 Responses to “Top C++ Programming Mistakes”
vitamin e says:
November 16, 2009 at 21:55
According to me, the programming mistake is occurred due to the lack of concentration in one’s own logic of programming. If the programming logic is good, there may be less chance of programming logic. The coding is always be done according to the standard rule. That rule must be followed.
[Reply]
Felix Halim says:
October 19, 2009 at 08:20
The hardest to find bug for me is when I code something, then I decided to change the algorithm (and of course change the code as well). At this point, if I miss changing something in the old code then it will produce a bug that is super hard to find. Hard enough so that I need to read again the entire code. Sometimes it’s faster to code from scratch rather than modify the old to new algorithm.
[Reply]