Scrap collection in C + +

Java enthusiasts often criticize C + + does not provide similar to Java garbage collection (Gabage Collector) mechanism (this is normal, as the C + + enthusiasts sometimes attack Java without this, or this does not good enough), resulting in C + + The official in the dynamic store is called the programmer's nightmare, isn't it? What you often hear is memory loss (memory leak) and illegal pointer access, which must be a pain in the neck, and you can't throw away the flexibility of the pointer.

In this article, I do not want to expose the inherent flaws of the waste collection mechanism provided by Java, but to point out the feasibility of introducing waste collection into C + +. Please note that the approach presented here is more based on the current standards and library design perspective than on the need to modify the language definition or extend the compiler.

1 What is scrap collection?

As a programming language that supports pointers, C + + gives programmers the convenience of dynamically managing storage resources. When you use objects in the form of pointers (note that because the reference is not able to change the language mechanism limits of the referenced target after initialization, the polymorphism application relies on pointers for most cases, and the programmer has to complete the allocation, use, and release of the storage itself, and the language itself cannot provide any help in this process, In addition to working closely with the operating system in accordance with your requirements, the actual storage management may be completed. In standard text, "Undefined (undefined)" is mentioned more than once, and this is most often associated with pointers.

Some languages provide a waste collection mechanism, meaning that the programmer is only responsible for allocating storage and use, and the language itself is responsible for releasing the unused memory, so that the programmer can get away from the work of annoying memory management. However, C + + does not provide a similar mechanism, the designer of C + + Bjarne Stroustrup The only one I have ever known to introduce the idea and philosophy of language design "the design and Evolution of C + +" (Chinese version: The Designing and evolution of C + + language) It takes a section to discuss this feature. In short, Bjarne himself believes that

"I intentionally designed C + + so that it does not rely on automatic scrap collection (usually directly to say waste collection). This is based on my own experience with waste collection systems, and I am afraid of the heavy space and time overhead and the complexity of implementing and porting waste collection systems. Also, scrap collection will make C + + unsuitable for many low-level jobs, which is one of its design goals. But I like the idea of scrap collection, which is a mechanism that simplifies design and eliminates many of the root causes of errors.

The basic rationale for scrap collection is easy to understand: Users are easy to use and more reliable than user-supplied storage management models. There are many reasons to oppose waste collection, but they are not the most fundamental, but the implementation and efficiency.

There are plenty of arguments to refute that each application will do better after the waste is collected. Similarly, there are plenty of arguments against it: No applications can be made better by the waste collection.

Not every program needs to run indefinitely. Not all code is basic library code; For many applications, a bit of storage churn is acceptable; Many applications can manage their own storage without the need for scrap collection or other related technologies such as reference counting.

My conclusion is that waste collection is needed, both in principle and in feasibility. But for today's users, as well as for universal use and hardware, we cannot afford to define C + + semantics and its base base on the waste collection system. ”

In my opinion, a unified automated waste collection system cannot be applied to a variety of application environments without incurring the burden of implementation. Later I'll design a specific type of optional scrap collector, and it's obvious that there's always some efficiency overhead, and it might not be advisable to force C + + users to accept this.

With regard to why C + + does not have scrap collection and possible efforts to do so in C + +, the aforementioned works are the most comprehensive of the topics I have read about this issue, although there is only a short section of content that has covered a lot of content, which is the consistent feature of Bjarne's writings, Concise and full of inner rhyme.

The following step-by-step to introduce my own homemade wine waste collection system, can be freely selected according to needs, without affecting other code.

2 Constructors and destructors

The constructors and destructors provided in C + + provide a good solution to the need for automatic release of resources. Bjarne has a famous saying, "Resource requirements are initialization (Resource inquirment is initialization)".

Therefore, we can request the resources that need to be allocated to complete in the constructor, and release the allocated resources in the destructor, so that the resource that the object requests to allocate is automatically freed as long as the object's lifetime ends.

Then there is only one problem, if the object itself is in the free store, the so-called "heap") is dynamically created, and is managed by pointers (believe you already know why), or you must explicitly call the destructor by encoding, of course, by using the pointer's delete expression.