Shulou(Shulou.com)06/02 Report--

This article mainly introduces "how is the deconstruction of C++ objects in the stack area". In daily operations, I believe many people have doubts about the destructions of C++ objects in the stack area. The editor consulted all kinds of data and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubts of "how the destructions of C++ objects in the stack area are". Next, please follow the editor to study!

As a C++ programmer, the most sensitive thing that distinguishes him from other object-oriented languages is the keywords new (malloc) and delete (free).

Today, when reading the boss's code, I found that when I reassigned a new insert element to a vector, I found that I didn't clear it first when I repeated the assignment of the COM object. I used to call clear at the beginning and * * when using the STL container, but after experimentation and debugging, I found that the elements in the vector can be destructed even if the object containing vector is not destructed without vector.clear ().

Later, I realized how stupid my previous idea was. STL's containers are all C++ objects, and since they are objects, they will certainly do some cleaning in their own destructors. If they don't have these, STL will not develop into a library of cymbal databases.

As a result, I think a lot about what vector did in clear. From an assembly point of view, all the variables on the stack will not cause memory leaks, so does vector really not have to call clear? No, the elements of vector are certainly not built on the stack, but on the heap. Why, the size of the array built on the stack must be determined at compile time, and why? I thought of a very typical example in school:

Int x; scanf ("% d", & x); char ch [x]

Trying to allocate x characters of an object by entering a number does not work. Why? At that time, the teacher only said that it was determined during compilation and could not be determined dynamically, but could only be written as

Int x; scanf ("% d", & x); char* ch = new char [x]

This is already allocated on the heap, and the run time will be dynamically determined later. So why on earth can't the space on the stack be dynamically determined at run time? It is much easier to understand from an assembly point of view: the elements that can be moved on the stack are always at the top of the stack, nothing more than Push,Pop

Char ch [x]; int iMagnej

Just imagine, in the face of such dynamic allocation, how to generate instructions to establish the stack? because of the size that each instruction needs to occupy in the stack, the memory in the heap can be discontinuous and does not have to follow the stack principle of FILO, so it is quite flexible.

Now why STL containers are built on the heap, STL containers are often resizable, how can you ensure that the elements built on the stack can be resized at any time, unless you can guarantee it at the top of the stack at any time, obviously this is not realistic!

At this point, the study of "how C++ objects are destructed in the stack area" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.