My development leader once said such a paragraph "a good programmer is not how fast he writes the code, nor is he able to implement the function of the module, to realize the function of the business who will not ah, the important thing is his ability to solve, also said when the program error when you can quickly locate the error and solve it. ”
Yes, I also very much agree that the code can not be perfect, there may be strange bugs, especially the novice, make more mistakes, so, we write the program should have its own set of debug means, has its own log method, once the program error, We do not need to add cumbersome printing to the program to locate the wrong location, so as to speed up their development.
How does it count as a set of efficient debug tools? My idea is this:
In-process open a separate thread for Debug&info Center, where we can see all the printing information, easy to track the various program trends
Standardize a set of Log/print methods, and do not use simple printf, add appropriate log in the appropriate location
Today we'll finish by customizing a set of rules that belong to our log.
I. Type and level of information
We know that there may be a variety of anomalies in the program, some are very serious, one does not pay attention to the occurrence of coredump, and some anomalies just may affect the operation of the program, but not to hang out, some anomalies are hidden, although there is no obvious impact on the system, but do not add treatment is ultimately a hidden danger. If we use the printf statement for these exceptions, we cannot distinguish which exceptions are important and which are not, so we first have to classify the information into categories (severity). My division is this:
Fatal fatal error
Alarm errors that need immediate correction
Error required to be concerned with error
Warning warning, there may be some kind of error
Info General tip Information
Debug Debugging Information
The code definition can be written like this:
#define FATAL 1#define ALARM 2#define ERROR 3#define WARN 4#define INFO 5#define DEBUG 6
Second, the design of log
According to the level of printing we specified above, we can easily design the corresponding debug log, gossip less, first on the code:
#define MY_LOG (level, FMT, args ...) do{\ if (bit_on (debug_flag,level)) {printf ("[%s]:", __function__); printf (FMT, # #args); }}while (0)
Of course we also need to define a set of debug level methods, my idea is this:
Using Bit-map idea, define a number of unsigned int, and each one represents a level, such as a number of unsigned int can represent 32 levels
Define the corresponding Function/macro definition to set the corresponding bit
Based on these ideas, you can set up the following series of actions:
#define PRESENT_BIT32 (x) (((UInt32) ((UInt32) 1<< (x))) #define BIT_ON32 (M, b) (((m) & Present_bi T32 (b))! = 0) #define SET_BIT32 (M, b) ((m) |= Present_bit32 (b)) #define CLEAR_BIT32 (M, b) ((m) &= ~pre Sent_bit32 (b))
Explain:
Present_bit32 (x): position of the bit corresponding to level
Bit_on32 (M, b): Determine whether a person is 1
Set_bit32 (M, b): Set pointing to 1
Clear_bit32 (M, b): will be specified as set to 0
We used a macro definition to define a log with a level, so how do we use these logs? Here's how to use it:
650) this.width=650; "src="/img/fz.gif "alt=" Copy Code "style=" Margin:0px;padding:0px;border:none; "/>
if (pthread_create (&thread2_id, NULL, (void*) msg_sender2, null)) {My_log (FATAL, "create handler thread fail!\n"); return-1; }my_log (DEBUG, "I have recieved a message!\n"); My_log (DEBUG, "msgtype:%d msg_src:%d dst:%d\n\n", MSG->HDR.MSG_TYPE,MSG->HDR.MSG_SRC,MSG->HDR.MSG_DST);
650) this.width=650; "src="/img/fz.gif "alt=" Copy Code "style=" Margin:0px;padding:0px;border:none; "/>
Of course, you need to open the corresponding log switch before use, such as I want to see the debug log, you can do this:
Set_bit (Debug_flag, Debug);
In this way, we define the debug level of the system as Debug.
Say another print trick: Give your print color!
printf ("\033[46;31m[%s:%d]\033[0m" #fmt "errno=%d,%m\r\n", __func__, __line__, # #args, errno, errno);
The above printf when the Linux command line print out the color of the font, easy to distinguish between different kinds of debugging information, just add some color code, for example: here 46 for the background , 31 for the color of the font.
Using ASCII code is a color call with the following format:
\033[, M ... \033[0m
Which of the following "\033[0m" is the end of the previous color loading, restore to the end of the original background color and font color, you can change the following to try:
#define DEBUG_ERR (FMT, args ...) printf ("\033[46;31m[%s:%d]\033[40;37m" #fmt "errno=%d,%m\r\n", __func__, __line__, # # Args, errno, errno);
the color values for ASCII code are listed below:
Word Background color range : 49----Color :-----------
40: Black 30: Black
41: Crimson 31: Red
42: Green 32: Green
43: Yellow 33: Yellow
44: Blue 34: Blue
45: Purple 35: Purple
46: Dark green 36: Dark green
47: White 37: White
The memory color format is too troublesome, we make it into a macro definition, so it is much more convenient to use later.
650) this.width=650; "src="/img/fz.gif "alt=" Copy Code "style=" Margin:0px;padding:0px;border:none; "/>
#define NONE "\e[0m" #define BLACK "\e[0;30m" #define L_BLACK "\e[1;30m" #define RED "\e[0;31m" #define L_RED "\e[1;31m" #define GREEN "\e[0;32m" #define L_GREEN "\e[1;32m" # define brown "\e[0;33m" #define yellow "\e[1;33m" #define BLUE "\e[0;34m" #define L_BLUE "\e[1;34m" #define PURPLE "\e[0;35m" #define L_PURPLE "\e[1;35m" #define CYAN "\e[0;36m" #define L_CYAN "\e[1;36m" #define GRAY "\e[0;37m" #define white "\e[1;37m" #define BOLD "\e[1m" #define underline "\e[4m" #define blink "\e[5m" #define REVERSE "\e[7m" # define hide "\e[8m" #define CLEAR "\E[2J" #define CLRLINE "\r\e[k" //or "\e[1k\r" #define &NBSP;DEBUG_ERROR (Fmt, args ...) do{ printf (RED "[%s]:" none, __function__); printf (fmt, ## args); }while (0);
650) this.width=650; "src="/img/fz.gif "alt=" Copy Code "style=" Margin:0px;padding:0px;border:none; "/>
Effect:
650) this.width=650; "src=" http://img.blog.csdn.net/20170105222745167 "style=" margin:0px;padding:0px;border:0px; " />
So, I suggest that the log with the fatal class of fatal error levels be highlighted, and we'll be able to detect it the first time any such error occurs.
Linux Programming Custom Band-level log