john2020
Full Member level 5
Debugging Tips in C++
hi all,
I find some Hints on Debugging,which am sharing with you here.It's very important with respect to both the hardware and software.i hope this will be useful for all.The following are some ideas to assist you in debugging your code.
When you are initially writing some code and you want
to see what is happening, or if you have a program
that is aborting and you can't figure out why, it is
time to do some debugging.
You can do one of three things:
1) Step through the program by hand. This is very
time consuming and you may not do exactly what the
computer would do.
2) You can use a debugger if the system you are using
has one and you know how to use it.
3) You can put in some "footprints" in your code so
you can follow a path through the program. This takes
some time also, but you know exactly what the computer
is doing.
How do you put "footprints" in your C++ code?
If you have a small one-time program that is aborting,
but you can't determine where, use the following
simple statement to track the path to your problem.
Put the following line multiple places in your control
program code, starting in main(). The line shows the
file name and line number in that file where the
statement is located.
std::cerr << "In " << __FILE__ << " got to line " <<
__LINE__ << std::endl;
When you run the code, you will see the last statement
that executed. Look in you code, for that line and
then for the next std::cerr line. The abort is
happening between these lines. Put more debug lines
between the one that ran last and the one that didn't
run. Repeat this process until you find out where the
abort is happening. If you have multiple source code
files and the line causing the abort is in a function,
you may need to put more debug lines there, and repeat
the process until you get it to a single non-function
call line of code.
This will tell you where the error is, but not what it
is. You may still need to do some work to figure that
out.
Once you have the error corrected, delete or comment
out the debug statements.
If you have a complex program and you will be working
on the program for a long time, you may not want to
add debug statements and then comment them out and
then uncomment them for the next bug and then comment
them out, etc. There is another method using the same
statement but also letting the preprocessor do the
work of commenting them out when you don't need them
and uncommenting them when you do.
At the top of your code, put the statement:
#define FOOTPRINT
Then within your code, put statements like:
#ifdef FOOTPRINT // causes conditional compile
// checking value of xyz to make sure it is less
than 20
std::cerr << "In " << __FILE__ << " on line " <<
__LINE__
<<" xyz = " << xyz << "\nPress enter to
continue"
<< std::endl; // or similar output message
// make sure the above message is meaningful
std::cin.get(); // to stop the program to read the
footprint
#endif // end of conditional compile
It is a good idea to comment each footprint, so you
know why each one is there.
Where to put "footprints"?
If you are tracking variable values, put a footprint
after the variable changes. If you are doing a
calculation with multiple variables, display all of
the variables.
If you are trying to find an abort, initially put a
footprint before and after each function call in
main(). This will identify which function is aborting.
Then put footprints within that function. This will
usually get you down to the line that is causing your
problem. Check that line of code very carefully. If
you cannot find anything wrong with that line, see
what variables are in that line and output of those
variables in your footprints also. This will help you
to see where the variable value goes bad. These are
harder to track, but it can be done.
Clean up
When you find and correct your error, change the
#define FOOTPRINT statement to a comment (//#define
FOOTPRINT). This will cause all of the footprints to
be ignored. If you need them again, just uncomment the
#define FOOTPRINT statement and all of your footprints
will reappear.
If you have multiple source code files, you may want
to put the #define FOOTPRINT statement in a separate
header file included in all programs, then you only
need to comment it out one time for all files.
When you are totally finished, then delete the
footprints. If you are in the real world, no program
is ever totally finished -- there will always be
changes to it, so the footprints are always there when
you need them.
Happy debugging!!!
regards
john
hi all,
I find some Hints on Debugging,which am sharing with you here.It's very important with respect to both the hardware and software.i hope this will be useful for all.The following are some ideas to assist you in debugging your code.
When you are initially writing some code and you want
to see what is happening, or if you have a program
that is aborting and you can't figure out why, it is
time to do some debugging.
You can do one of three things:
1) Step through the program by hand. This is very
time consuming and you may not do exactly what the
computer would do.
2) You can use a debugger if the system you are using
has one and you know how to use it.
3) You can put in some "footprints" in your code so
you can follow a path through the program. This takes
some time also, but you know exactly what the computer
is doing.
How do you put "footprints" in your C++ code?
If you have a small one-time program that is aborting,
but you can't determine where, use the following
simple statement to track the path to your problem.
Put the following line multiple places in your control
program code, starting in main(). The line shows the
file name and line number in that file where the
statement is located.
std::cerr << "In " << __FILE__ << " got to line " <<
__LINE__ << std::endl;
When you run the code, you will see the last statement
that executed. Look in you code, for that line and
then for the next std::cerr line. The abort is
happening between these lines. Put more debug lines
between the one that ran last and the one that didn't
run. Repeat this process until you find out where the
abort is happening. If you have multiple source code
files and the line causing the abort is in a function,
you may need to put more debug lines there, and repeat
the process until you get it to a single non-function
call line of code.
This will tell you where the error is, but not what it
is. You may still need to do some work to figure that
out.
Once you have the error corrected, delete or comment
out the debug statements.
If you have a complex program and you will be working
on the program for a long time, you may not want to
add debug statements and then comment them out and
then uncomment them for the next bug and then comment
them out, etc. There is another method using the same
statement but also letting the preprocessor do the
work of commenting them out when you don't need them
and uncommenting them when you do.
At the top of your code, put the statement:
#define FOOTPRINT
Then within your code, put statements like:
#ifdef FOOTPRINT // causes conditional compile
// checking value of xyz to make sure it is less
than 20
std::cerr << "In " << __FILE__ << " on line " <<
__LINE__
<<" xyz = " << xyz << "\nPress enter to
continue"
<< std::endl; // or similar output message
// make sure the above message is meaningful
std::cin.get(); // to stop the program to read the
footprint
#endif // end of conditional compile
It is a good idea to comment each footprint, so you
know why each one is there.
Where to put "footprints"?
If you are tracking variable values, put a footprint
after the variable changes. If you are doing a
calculation with multiple variables, display all of
the variables.
If you are trying to find an abort, initially put a
footprint before and after each function call in
main(). This will identify which function is aborting.
Then put footprints within that function. This will
usually get you down to the line that is causing your
problem. Check that line of code very carefully. If
you cannot find anything wrong with that line, see
what variables are in that line and output of those
variables in your footprints also. This will help you
to see where the variable value goes bad. These are
harder to track, but it can be done.
Clean up
When you find and correct your error, change the
#define FOOTPRINT statement to a comment (//#define
FOOTPRINT). This will cause all of the footprints to
be ignored. If you need them again, just uncomment the
#define FOOTPRINT statement and all of your footprints
will reappear.
If you have multiple source code files, you may want
to put the #define FOOTPRINT statement in a separate
header file included in all programs, then you only
need to comment it out one time for all files.
When you are totally finished, then delete the
footprints. If you are in the real world, no program
is ever totally finished -- there will always be
changes to it, so the footprints are always there when
you need them.
Happy debugging!!!
regards
john
