Experiences in Object Memory Management

I have to say that C/C ++'s powerful functions and flexible manipulation have always been my favorite. The philosopher said that everything has two sides to its conflict, and I will not be bullied! C ++, you handed over the great memory management work to us, but we often don't use you well.

 

The most common problems with object memory management are:

1. Memory Access conflicts. The specific manifestation is that a warning box "0xfa012345 ...... The memory cannot be read ." OK, the program crashes.

2. Memory leakage, which is rarely shown because the current machine is getting stronger and stronger. But once the memory is insufficient, the problem will be very serious and Uncle Li will be very angry.

 

There are several types of codes that cause memory access conflicts:

1. Memory out-of-bounds access, such as an array over-bounds operation

2. The object pointer does not correctly point to a valid object and still accesses its members (read and write member variables, call member functions, and delete object itself ). Specific situations include:

A. When the object pointer is null, it still accesses its members.

B. If the Object Pointer does not specify the object correctly, the user still accesses its members. If Initialization is not performed, the pointer is randomly directed to the system memory or the object has been destructed, but the pointer is not notified.

 

The most fundamental cause of Memory leakage is the memory allocation (new) not released (delete ).

 

One of my most common errors is that, to prevent memory leaks, the delete operator is often used too much, resulting in memory access conflicts, because the object is deleted after being deleted. Of course, the first delete operation was performed in other modules, and I could not even predict when it was deleted.

 

Systems (programs) are a little more complex, so you have to use various containers to save objects (usually pointers or references). These objects are generally shared, and the methods of creating objects are diverse and location uncertainty, the two most common problems occur in Object Memory Management mentioned above.

 

The predecessors have long been able to cope with these "low-level" problems, that is, smart pointers and reference counts. Experts are even prepared to write these features into the new C ++ standard.

 

I have never had the courage to use it. I am afraid that using smart pointers and reference counts will greatly reduce the program's performance. After all, it is necessary to have more access. But this is still an excuse. The most fundamental reason is that I am lazy and too lazy to use it. Think about it. Every time I get object (), I need pobj-> release (), I can't stand it anymore. Another excuse is to fear that these advanced features cannot be understood by every member of the project team, and they are harmed by improper use of their own tools.

 

Smart pointers and reference counts are not used. To avoid problems and confusion caused by memory management, I can only specify them in the form of annotations and documents in the class interface functions, the input or output objects (pointers) are managed by the external customer code (mainly creation and destruction), or by the class itself. Do not worry about the external objects. In the future, whether it is the specific class implementing the interface or the customer class using the service, you must strictly follow this agreement.

 

However, the role of this object memory management statement is still limited, but the Xiaoming culture is gone.

 

Find a more perfect solution ......