[C++ Notes] Common pitfalls in using C/C++ pointers

The pointer in C/C++ gives programmers more flexibility, but it is also a double-edged sword. If you don’t use it well, it will cause various problems in your program. Some people say, C/C++ programmers spend half of their workload on dealing with bugs caused by pointers. One can imagine how terrible the traps contained in pointers are. That being the case, we should check it out when we write code.

If you want to avoid the problems caused by pointers as much as possible when writing code, you need to know what problems might be caused by improper use of pointers, and how to avoid them? Let's summarize the problems that are easy to encounter when using pointers.

Avoid memory leaks

The program needs memory when it is running. At the same time, we also know that memory is limited, which is a particularly valuable resource of the computer. The used memory should be returned to the operating system in time.

In c/c++, if it is memory on the stack (for example, local non-static variables in a function), after use, the operating system will automatically reclaim it for us; but if it is memory on the heap obtained through dynamic allocation, We need to release it manually.

If we forget to release these dynamic memory in the program, and the program is a service process that will continue to run, it will cause the memory usage to become higher and higher, the lighter can be disabled and the system performance will be affected, and the more fatal will cause the process to crash.

In a word, if the memory that is no longer used is not released, it is called a memory leak, and the problem of memory leak is very serious. Okay, let's look at a few cases of memory leaks.

In C/C++, the dynamic memory allocated through dynamic memory allocation functions (such as malloc system functions) or the new operator needs to be manually released after use. Otherwise it will cause memory leaks.

Suggestion: Pay attention to the use of malloc/free, new/delete in pairs when writing code

Even if free/delete is called to release the memory after malloc/new, the free/delete statement that releases the memory may not be executed due to exceptions, and memory leaks will occur. This is the case in the following example.

From the running results, the destructor of the class is not executed, and it can be inferred that the delete statement is not executed.
Some people will say that this is not easy, just add delete t after the catch statement cout << "Something has gone wrong" << endl;
That's right, this is just a test program with dozens of lines of code. You may see the problem at a glance, but if you are facing a huge project, I think your heart must be broken. There is a better way to solve this problem, that is, smart pointers, which will be introduced in a special article later.
Recommendation: Pay more attention to the use of smart pointers in C++ code

Don't use wild pointers

Wild pointers are also called dangling pointers. They are pointers to "garbage" memory. Using "wild pointers" will cause the program to exhibit uncertain behavior.

Note that wild pointers are not NULL pointers. They are more prone to making mistakes than NULL pointers because they cannot be prevented by judgment statements of the form if (NULL == p). We can only pay more attention when writing code.

After the pointer p is free or deleted, it is not set to NULL, which makes people mistakenly think that p is a valid pointer. In fact, free or delete only releases the memory pointed to by the pointer, but the value of the pointer is still the address of this memory. It's just that this memory has been reclaimed and cannot be reused by the process. The following example is a typical case of using wild pointers.

Suggestion: set the corresponding pointer to NULL after free or delete

I forgot to initialize when creating the pointer variable p. The value of p is a random garbage value. At this time, it is dangerous to read and write the pointer, and the program will produce uncertain behavior.

Suggestion: try to initialize when defining pointer variables, even if the initialization is NULL

In c/c++, local variables are stored in the stack. Its characteristic is that it is created when the function is called and destroyed when the function ends. Therefore, the address of the local variable is assigned to a pointer in the program after the return, and the pointer points to A memory that has been reclaimed is also a kind of wild pointer.
Take a look at the following example. I originally wanted to return the address of the variable i in the fun function to p, and use p to access this variable. This prints out that *p is 32767, not the value of variable i. Such bugs are difficult to locate once they appear in a large project.

Suggestion: Do not return the address of a local variable in a function. If the logic of the code must be the address of a local variable, then the local variable must be declared as static, because the lifetime of a static variable is the entire program running period

Don't use NULL pointers

Everyone knows that you can't use NULL pointers in programs, but if you don't pay attention, you may still use NULL pointers in programs unexpectedly. Here are two examples that are prone to problems.

When the dynamic memory allocation function allocates memory, it may fail to allocate. At this time, NULL is returned.


From the program running result, malloc allocation fails and returns NULL to p, and then accesses the memory content at address 0 pointed to by p. "Segmentation fault" error.

Suggestion: When using the memory allocation function to allocate memory, you should use if(p==NULL) or if(p!=NULL) for error prevention.

In addition, in functions containing pointer parameters, it is also possible to misuse the NULL pointer. The pointer passed when calling the function is a null pointer. If there is no if (p!=NULL) judgment condition, then the pointer will be used later The trouble will be big, the following example is this situation.

Suggestion: For functions containing pointer parameters, if (p==NULL) or if (p!=NULL) should be used at the entry of the function for error prevention.

Recommended reading:

Carefully organized | The article catalog
in the second half of 2017 Deeply understand the log mechanism in the system (Part 2)
[C++ Notes] Understand the dual meaning of typename
[C++ Notes] Memory layout of C++ object model (2)

Focus on server background technology stack knowledge summary sharing

Welcome to pay attention to communication and common progress

Coding

The code farmer has the right way to provide you with easy-to-understand technical articles to make technology easier!