Some Suggestions for c++ code debugging

1. The importance of code debugging

Code debugging plays an important role in the program development stage, so we can see the importance of code debugging. But one thing must be emphasized: programs are designed, not debugged. This is one rule that all programmers must keep in mind. A poorly designed or poorly designed program, no matter how it is debugged, is not a qualified program.

Under the premise of a well-designed program, coding errors are inevitable in the process of software development. All errors that can occur in a program fall into two categories: syntax errors and logic errors. Debugging is usually the process of finding logical errors in a program after the syntax errors have been eliminated. For C/C++ program debugging, there is such a common means of concentration. They can be used alone or in combination.

2. Several Suggestions on code debugging

2.1 Use print statements

This is the simplest and most direct way. The operation of a program can be seen as a process of changing a set of variables (states), which is the process of data processing. If the end result of the program is wrong, then we have to consider when the 1 set of states is wrong, and looking at the intermediate results is the most effective way to do this.

So don't get too carried away with powerful debugging tools. In most cases, the problem with the program is a minor one. And it is these small problems that cause big problems. Programmers can do this by using simple printf() statements or cout near the most error-prone code < < ... Statement to output the intermediate result to see the exception.

2.2 Use the debug flag

It is a common debugging strategy to use the corresponding auxiliary code (such as output intermediate results, etc.) when debugging the program and hide the code after debugging.

This strategy can be implemented with the help of #define, #ifdef, and #endif compilation instructions. Specifically, when debugging a program, you define the debug flag using the compiler's command-line arguments (equivalent to the macros defined in #define), and then include the corresponding debug code between #ifdef and #endif. When the program is finally debuggable, the debug code in the program disappears as soon as the debug flag is no longer provided in the compiler command-line arguments during the build of the distribution. The common debug flag is _DEBUG (in VC++ 2012). The compiler debug version of the program defines the macro _DEBUG by default. Consider the following procedure.

#include <iostream>
using namespace std;

int main()
{
	int i=5;
#ifdef _DEBUG
	cout<<i<<endl;
#endif
	cout<<"Hello World!"<<endl;
}

When debugging a program, statements between #ifdef and #endif are executed. When debugging is complete, the debugging code is hidden because the debugging tag _DEBUG is undefined.

2.3 Use debug variables

Similar to the way debug markup is used, you can set up an bool type variable for debugging at run time, whose value determines the opening and closing of specific debug code. The variable can be switched on and off using the command line parameters of the program. The above program has been modified as follows.

#include <iostream>
#include <string>
using namespace std;

bool debug;

int main(int argc,char* argv[])
{
	int i=5;
	for(int j=0;j<argc;++j)
	{
		if(string(argv[j])=="debug=on")
		{
			debug=true;
		}
	}
	if(debug)
	{
		cout<<i<<endl;
	}
	cout<<"Hello World!"<<endl;
}

When the program is started from the command line, it can output debugging information as long as debug=on is specified in the command line parameter. Otherwise, it is only the part of the output program that runs "normally." This allows for greater flexibility.

2.4 Use the built-in debugging macros

During program debugging, you often want to know which module is currently running which function is smaller, which line is in the source file, and so on. If this information is added manually, it will undoubtedly put a great burden on the programmer. Therefore, C++ provides several macros, and they are respectively __FILE__ , __FUNCTION__ and __LINE__ , you can use them to "automatically" get information about modules, functions, and rows. Consider the following procedure.

#include <iostream>
using namespace std;

void func1()
{
	cout<<__FILE__<<endl;
}

void func2()
{
	cout<<__FUNCTION__<<endl;
}

void func3()
{
	cout<<__LINE__<<endl;
}

int main(int argc,char* argv[])
{
	func1();
	func2();
	func3();
}

Output the following information on my machine:

[

e:\lvlv_study\synchronousfile\school\2015.10.23\programming\debug\main.cpp
func2
13

]

You can also use the assert() macro for assertions. assert is a macro that only works with debug versions. In addition, users can define their own macro assistance to complete debugging tasks. For example, the following red can be used to display the value of a variable, and the name of the variable will be shown as 1:

#define PR(x) cout<<#x " = " <<x;

This is a string manipulation of macro parameters using #.

2.5 Use debugging tools for debugging

Debugging with an INTEGRATED development environment is also a rule. You can set breakpoints in IDE, but not debug, look at the memory value of the variable, dynamically modify the value of the variable to change the execution path of the program, and so on. Each of the specific debugging tools has different debugging commands and methods, and you should refer to the corresponding documentation (MSDN, etc.) when using it.

One point to note is that, in addition to the ease of use differences between tool debugging and print-based debugging, in some special cases, it is difficult to debug some programs with a tool without being alive. If you want to debug code related to window redraw in Windows programming, IDE is not appropriate for debugging. The reason is that when the focus shifts from the IDE window to the application window, a new redraw action is triggered, causing the program to run in an "endless loop." Under Linux environment, for code debugging, we can use the powerful debugging tool gdb, which can quickly locate the location of the program error, such as using bt or where command can quickly find the location of the program core dumped.

3. Summary

Use a variety of debugging tools, the purpose of which is to find errors that already exist in the program as early as possible. Associated with this is the question of how to introduce fewer errors and how to use debugging tools strategically. Here are a few Suggestions.

(1) Adopt a good style. For example, variables, functions, and types are named using the unified 1 specification. The basic units of the program (e.g., functions) should be within a range of 1 (e.g., 100 lines), zigzag coding, reasonable comments, etc.

(2) Conduct code review. This is the practice advocated by the ES10106EN (Personal Software Process, personal software process) specification specified by the research team led by Watts Humphery. Code review before compilation is a much more effective way to find bugs in a program than compiling directly.

(3) Statistics and tracking of historical data. Every programmer's background and work habits are different, so it is an effective way to improve the quality of the program by counting the types of programming errors that are most likely to occur in the past.

Above is the c++ code debugging method of the detailed content of a few Suggestions, more about C++ code debugging information please pay attention to other related articles on this site!