Up to back, RAII is incompatible with existing GC environments, and it also mentioned the problem of the problem of the destruction function. This is not just a regrettable coincidence, thinking about it is not difficult to find, after this contradictory, it is actually the difference between "How to see an object".
As mentioned earlier, the core content of RAII is to host the resource to the object, and ensure that resources are always valid in the object life cycle. In this way, we actually convert the tasks of management resources into tasks for management objects. You have objects equal to having resources. There is a certain resource, and vice versa. All the power of RAII originated here. The starting point of this approach, in the words of Bjarne Stroustrup, is "Use An Object To Represent A Resource" (comment from the code stored in this article). In other words, in the eyes of RAII, the object represents resources. Its behavior and status should be exactly the same as the behavior and status of resources, so the application and release of resources should naturally be related to the structure of the object. For most resources, the programmer has the right and needs to control when it is released, so natural, the programmer should have the power and need to control when it is designed. One words, this requires the programmer to control the life cycle of the object.
However, existing GC environments do not satisfy the above conditions. In this article, it is introduced that for GC, how long the life cycle of an object is no right to interfere, the object a, whether it is survived must be strictly in accordance with the root from the root The pointer chain can reach A "to determine. In the eyes of GC, the object is just a partitioned memory, and history has proven that determines when the memory is released to release this task, which cannot be handed over to the programmer who makes mistakes, should be completed by a special collector to ensure each memory recycling action It is safe. what? An object represents a resource? what! I only have memory in my eyes, there is no resource!
Hey, the role of the object in the eyes is so big, it is no wonder that the water is not allowed. However, this contradiction is really no possible? It is not seen in it. RAII values the semantics of the object, so that the object represents resources, therefore requested programmers to control the life cycle of the object, and only memory in GC, repeatedly emphasizes that only allows the collector to recover memory to ensure security, this can't make programmers . Therefore, it is necessary to meet the requirements of the two, the life cycle of the object and the release of the must be released with the memory. This is not a fresh idea. In fact, according to the definition of the C standard, the lifecycle of an object begins with the constructor, and finally the destructor, it is not determined by memory allocation, and Placement New is extremely fully, assigned this performance. Memory, constructive objects, destructor, and release memory four operations clear, independent. At this point, our solution has come out. On the one hand, we have to hand over the responsibility of the release memory to the GC, and it is necessary to allow the programmer to control the object life cycle, then the correct way is ...
Based on the existing GC mechanism, the programmer is allowed to explicitly destructively dominant, and when the program is trying to access the destructed object, it will throw an exception.
This is very ridiculous (I can see the countless eggs and tomatoes of the stage ... Hey ?! You really smash it?), But it is not the case. First, the allocation and release of memory is managed by the GC mechanism. All the memory that the pointer can be reached is always valid, so we have the same security guarantee - no suspension references and memory leaks, so we can rest assured that it is bold in the module There is no need to worry about the problem of hanging references, and you don't have to worry about the details of memory management. The interface between the "Stroke" module; secondly, the programmer can control the life cycle of the object, so we can Continue to apply the semantics of RAII "Object Representative Resources" and enjoy the convenience it brings; Finally, trying to access the destructed object will throw an exception, block the mouth of unfained behavior. In a word, now we can put the object into the pile of support GC without having to change its semantics. ! Isn't it a good cooperation on both sides?
It must be recognized that it is actually very simple, but I know that there is currently no GC environment support. This is because most of the language of the GC does not have language features such as the destructor in C , in other words, the root does not apply RAII, and C itself does not support GC. Well, in the face of this situation, I decided to effect the sage - I realize a garbage collection library for C , with a smart pointer to implement the control of the pointer access, and provide an explicit destructor interface.
Finally, I will try to answer some questions that may have:
Q: What is the difference between explicit sectors and explicit calls? Do you want the programmer to do it yourself? A: There is a difference. Please refer to this article, with regard to the advantages of RAII relative to explicit release resource programs.
Q: You allow programmers destructure objects, then you may have a pointer to a destructed object, which is not the same as the suspension pointer? A: Different. If you try to access a destructor, you will only throw an exception (of course, this has to be implemented through the smart pointer), and the access to the hanging pointer ... don't use me more?
Q: (Continued) This way, through the pointer access object may throw an exception, this is not. A: This statement is not accurate. Under the existing GC mechanism, the resource occupied by the object needs to be invoked (for example, the Close member function explicitly released, and after the CLOSE is called, try to access this object, will throw an exception, indicate the resources required to use this object. Already released. Moreover, for existing scenarios, each object releases the function of the resource may vary, identifying the exception of "resource release" may be different, but if the explicit segment is used, the means of releaseing the resource is consistent (analysis) Structure, identifying an exception of "resource invalid" is also consistent ("object destructure"), which greatly reduces the contractual burden of programmers.
Q: (Continued) But do you check? Each pointer access requires checking whether the object is destructed, the efficiency is too low. A: This statement is not accurate. The scheme of explicitly calling Close releases the resource, within which the member function of each completed substantive job (so the resources required to access the object) must also check if the resource is valid, also an inspection. Moreover, such an inspection programmer needs to write for each class, and the above-mentioned explicit destructure is used, only the intelligent pointer needs to do this. Q: (Continued) How much is your answer to your two questions? Not each member function of the object requires access to resources, and the above two arguments are not established for member functions that do not need to access resources. Moreover, not all objects need to manage resources. If I want to put an int in supporting GC, what should I do? In this way, "may be throwing" and "more inspections" are undoubtedly two big shortcomings? A: Well, this may be the most powerful question, my answer is this: I will additionally provide an intelligent pointer that does not support explicit destructors, and its use is like a pointer in the traditional GC environment. There is also a problem that "may throw itself" and "more inspections". In other words, if your object does not manage resources, or you must continue to access objects after resource release, you can return to the traditional GC scheme.
Q: I just don't like your idea! Have you seen it? A: ... no opinion. If you really can't accept the idea of "Explicit Destructure", you can only use another smart pointer mentioned above - um, in addition to "Explicit Destructure", I am specific in C There are many other ideas in achieving garbage collection mechanism. In addition to "explicit destructors", my collector should have other advantages. Of course, this is the content of another article.
Ok, roughly is the case, I hope everyone will give more opinions. If this is interested in implementing the garbage collector, please click here: http://www.AllaboutProgram.com/bb/viewtopic.php? T = 1520
