Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to analyze and study the content of C++ Resource Management

2025-01-18 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

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

This article introduces how to analyze and study the content of C++ resource management. The content is very detailed. Interested friends can use it for reference. I hope it will be helpful to you.

Next to explain the problem of C++ resource management, then first of all to understand the concept of C++ language, the so-called C++ language: it is a very widely used computer programming language. C++ has become one of the most complex programming languages in today's mainstream programming languages.

First of all, a brief introduction to RAII. The basic technique of this idea is to write a guard class for a resource that you want to use, request the resource in the constructor of this class, and release the resource in the destructor. For example, suppose we want to manage a mutex, possibly by:

Struct lock_guard {lock_guard () {lock ();} ~ lock_guard () {unlock ();}}

After that, what memory management method is used for this object is equivalent to what memory management method is used for this mutex. With the help of RAII, we can only discuss the management of memory resources in the future, and the management of other resources can be implemented using RAII.

Now we have naturally obtained three ways of resource management: heap-based dynamic mode, stack-based automatic mode and global mode. It is worth mentioning that the latter two of these three approaches, which are less error-prone, can actually solve most of the resource management requirements.

Because most of the resources belong to the get-use-release type, such as many synchronization objects, file locks, and many GDI objects in WinGDI. We lack management, only a few resources that are acquired at once, owned by multiple environments, and can only be released at one time.

Going back to the memory model, one thing that makes it impossible to equate memory with other resources (conversely, it is possible to equate other resources with memory) is circular references.

A memory can hold a reference to B memory, and B memory can in turn hold a reference to A memory. Circular references make it impossible for memory management to distinguish whether a piece of memory can be reclaimed by "whether there is a reference to that memory". As a result, a management tool is lost. However, in the absence of circular references, we still have a very simple and efficient management method. That's the reference count.

Reference counting is a means of memory management without circular references. it has the advantages of lightweight, efficient, real-time and controllable. And in C++ resource management, reference counting has been very mature, only need to use boost.shared_ptr or other unofficial reference counting pointer library, and it is reported that C++ resource management is likely to include boost.shared_ptr into the standard library.

The principle of reference counting is that if an object has no other pointer or reference to it, then the object can be released. Where can resource management problems be handled by reference counting? First of all, for one-way resource management, that is, multiple An entities have a B, however, B does not in turn depend on A (for example, multiple objects share a log), and reference counting is very appropriate.

Second, for situations where there is reaction, that is, the entity of one or more A has one or more B, and B also has references to the entity of these A, but the lifetime of B is still determined by the lifetime of A (for example, the parent window has several child windows, and the child window also has a parent pointer to the parent window.

But the lifetime of the child window depends on the lifetime of the parent window. At this time, A can use reference count pointers for B, while B can use native normal pointers for A, which can also solve the problem. Now all that is left is the cyclical dependence of the lifetime. If the AB holds references to each other, and the existence of the AB depends on each other, the reference count cannot be solved.

But if you think about it, this situation is almost impossible in C++ resource management. There are only two consequences of lifetime cyclical dependence, either destructing each other in the destructors of An and B (dead, of course) or not destructing each other (leaked, of course).

Both of these are things that don't happen in normal programming. So even if we just use reference counting, we can solve almost all resource management problems. Now look back at the built-in gc language like Java/C#. Such languages inevitably abandon destructors because of the use of gc. Why does gc conflict with destructors?

A gc generally wants the whole process to be atomic during garbage collection, but destructors break this, and if code is executed when memory is freed, it will inevitably have a destructive impact on the entire gc environment.

Without destructors, it is impossible for these languages to achieve RAII, that is, all their C++ resource management can manage is memory. For other resources, Java and so on must be released manually. Although C# provides the with keyword to alleviate this problem, it still can not be solved completely.

On how to C++ resource management content analysis and research is shared here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report