Dev-CPP/mingw32 Environment Introduction (3)

Dev-CPP/mingw32 Environment Introduction (3)

Review above:

The above Dev-CPP/mingw32 Environment Introduction (2) introduces some Dev-CPP functions, including package installation and some minor functions. Hope you will be satisfied. This time, we will continue to introduce other features of Dev-CPP. Actually, tell the truth. For GNU, I personally feel comfortable using it at the prompt. I don't know why. There are many functions. You can simply enter a few characters at the prompt to complete the functions that Windows IDE requires a lot of mouse clicks. I said this is not an unreasonable plug-in. This time, I will show you my point of view.

 

Chapter 5 program debugging under Dev-CPP

 

For any programmer, the debugging of the program is no longer necessary. If there is no program debugging, where can we start with the stability of the program? Now let's take a look at how to use Dev to debug our dear program.
As we all know, GNU has a very good debugging program GDB, but it often uses VC. Therefore, many people have heard of this program but have not witnessed it. Now let's open his cover. First, we started Dev-CPP. What we need to do this time is to debug the program under Dev-CPP. In Dev-CPP, the debugging program does not have a special program interface as in VC. The debugging interface is under the Code box. Select the debug tab below to view the debug interface.
After you see the debugging interface, will it feel miserable? In fact, I have been miserable for several years. You will have a look. The debugging tab has three options. Debugging, backtracking, and output. Among them, debugging is to make some Debugging commands into buttons for your convenience. However, I personally think this function is convenient and inconvenient. In some cases, this is a simple operation that will make the user confused. Tracing is to display information about the functions of the gdb call. This function is not bad. The output is to directly output the user's GDB command to the gdb program without a button, but this interface has a bad point, that is, the window showing the information returned by GDB is too small. It is quite uncomfortable to have a look at the leopard.
I think it is a bit cool to say so much. Are you all itchy? (Isn't it pediatric ADHD ?) Now you can open a program at will, preferably a program with multiple lines of code, multiple parameters, multiple functions, and prompt interface. This helps you understand the basic operating mechanism.
Click the debug button in the debugging window. If your program does not have debugging information, Dev will prompt you whether to re-compile the program and add debugging information. Select Yes. Then the program will re-compile the Connection Program in debug mode. After completion. Let's start with our own program. First, run GDB. Click debug next time, or move the cursor in the editing area to the position where you want to run and click Run to the cursor. Then, the program starts to run. Here, you will see a blue note in the editing area. This indicates where the program runs. If you want to, you can continue to run the next line. You only need to click Next. Other operations related to GDB, such as code viewing, variable viewing, and function information, can only be achieved through output. Select output and enter your GDB command in the output character input box. For example, the LIST Command will list the program code in the following character box. Of course, you need to look up and down, because the box is too small, it looks very troublesome.
Now, I will introduce debugging in IDE. Of course there are no more in-depth things in depth. I am afraid that I am not exhausted, but you may be bored. In fact, some operations described above can be easily OK if you try again. It does not need to be so complicated. I think, maybe this is one of the main reasons why Dev is not popular. Because the interface operations are too unfriendly.

 

Chapter 6 program debugging at the prompt

In the previous chapter, we learned about debugging under Dev-CPP. This is really not a compliment. Next, let's take a look at the standard, classic GDB debugging. If you have some knowledge about Linux and other systems, you should know that the prompt is a common interface of many classic software. Therefore, to use some classic things, you should be familiar with them at the prompt. Of course, the prompt here is not as troublesome as you may think. There are hundreds of commands to remember. In fact, a program like GDB is basically a very simple command. And flexible.
Next I will introduce the debugging of GDB.
First, we must have a code that can be debugged. Now we use GCC main. C-o main-g to generate debugging code. Start GDB with GDB main. Isn't it as complicated as you think? If it succeeds, you will see a piece of GDB copyright information, followed by a prompt such as (GDB. Now you can run the command on GDB.
Look at the program code. If we want to check the source code of the debugging program and do not want to open the main. c file (the reason is that we need to set breakpoints later ). Then we can enter list or L to view the program code. Right? It seems that the prompt is not as terrible as we think.
Run the program code. Although debugging works, how can we run the code during debugging? Very simple. Enter run or R to run. If you have set a breakpoint before, you can use this command to run the program to the breakpoint.
Set breakpoints for debugging. You can use break to set breakpoints so that the debugging program stops running at the breakpoint. The break must be followed by a parameter. The parameter can be a row number. For example, break 10 sets a breakpoint on line 10. It can also be the function name break main, that is, the breakpoint is set at the main function.
View program variables. If you want to view the variables in the program, you can use the paint or p command. These two commands must be followed by the variable name. For example, P argc indicates the value of argc. The info command can be used to view related information, such as the memory location or something.
Run the program step by step. If you execute a program step by step after a breakpoint, you can use the N or next command to execute the next line of code.
Exit debugging. Enter Q to exit the program.

Do you think debugging at the prompt is easier than debugging in IDE? Do not assume that this is all the functions of GDB. I will show you GDB here. If you want to learn more about how to use GDB. You can view the technical manual or find related articles online.
Finally, if you have any questions about GDB and the debugging program, we can discuss it together.

VOICEOVER:

This article seems very short, so I think. However, there is no way. The so-called public tone is difficult. This chapter is always about. Simply write it in advance. In the next article, we will go to Project Creation and static library usage. I think it will make you feel excited. Finally, I hope you can give me more advice. My motto: whether it is ideology or program, it can be improved only through continuous communication.

 

Studio software development team

Dipper (Huang yaokui)