C + +: Some bugs about memory

In terms of memory management, C # is a perfect haven, you don't have to manage your memory as carefully as you do in C + +, but I prefer C + +, as Microsoft calls C + + as native code-C + + for me, it is really more native.

In fact, a lot of times, C + + in C #, like manual block in the automatic block.

Gossip does not matter, in general, we will encounter memory problems with the use of uninitialized pointers, using a null pointer, releasing the memory has been released and so on. I have also encountered two memory related problems in my recent work, and I think it is worth remembering.

Who assigns, who releases

The object of a class provided by a third party will be crash each time it is destructor. After careful examination, we found that we were new to a piece of memory and set the pointer to a member of the object (OBJECT.P). The class is therefore suspected of attempting to delete the block memory in the destructor. Try to put the OBJECT.P 0 before the destructor, the problem no longer exists, so the basic can be sure that this is the reason.

There are actually two problems, one is that our code does not release their allocated memory, and the second is the code of the third party library, should not delete the memory that is not allocated by itself. Who assigns, who releases is a fairly important principle, a third-party library that tries to release the memory from the user new, at least the following problems:

In general, using the memory that will release the new one, there will be two release problems.

If either side overloads the operator new and operator delete and defines its own memory pool, then the basic is're same page.

What if it's an object on the stack, and you delete it?

Inadvertently corrupted memory

We have a transaction manager based on memory, the basic principle is that every data modification will be the modified memory back up, and then undo, the backup of the data will be overwritten back. Of course, here needs to be backed up by the memory that is allocated in a special way, which we call transacted memory. Consider the following process:

Make a data modification, such as drawing a circle

This operation requires dynamic loading of DLLs that provide circle-drawing functions

During the DLL loading and initialization process, a transacted memory was created, such as a std::map

When the circle is finished, do a undo operation

The newly drawn circle is then covered with the original memory, and at the same time, the std::map that was allocated during the loading of the DLL is also overwritten, noting that the process of loading the DLL is not being undo, so when the program attempts to access the map again, Because the content of the map is completely unrecognizable.

The bug took me 4 or 5 hours to discover the problem, and the solution was simply to avoid assigning transacted memory when the DLL was initialized.