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

This article mainly explains why the original pointer of C++ should not have ownership. Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Next, let the editor take you to learn why the original pointer of C++ should not have ownership.

R.3: the original pointer (T*) should not have ownership

Reason (reason)

There are no exceptions to this (whether it's the C++ standard or most of the code) and most of the raw pointers have no ownership. We need ownership pointers to be defined so that the objects pointed to by ownership pointers can be reliably and efficiently deleted.

Example (sample)

Void f ()

{

Int* p1 = new int {7}; / / bad: raw owning pointer

Auto p2 = make_unique (7); / / OK: the int is owned by a unique pointer

/ /...

}

Unique_ptr prevents memory leaks by ensuring the deletion of objects, even in the event of an exception. And T* won't.

Example (sample)

Template

Class X {

Public:

T* p; / / bad: it is unclear whether p is owning or not

T* Q; / / bad: it is unclear whether q is owning or not

/ /...

}

We can solve this problem by explicitly giving ownership.

Template

Class X2 {

Public:

Owner p; / / OK: p is owning

T* Q; / / OK: q is not owning

/ /...

}; Exception (exception)

The exceptions mainly come from existing code, especially those where ABIs must maintain C compatibility or contain a C or C style C++ interface. In fact, there are millions of lines of code that violate this rule against T* ownership, and they cannot be ignored. We are pleased to see that software tools can convert more than 20 years of old code into new and modern C++ code, we encourage the development, deployment and use of such tools, and we have even contributed to research in this field. and will continue to contribute. However, this takes time: "existing code" is generated faster than we can renovate old code, so the process will continue for some years.

It is not possible that all code can be rewritten (even if there is good conversion software), let alone soon. This problem cannot be solved by converting all ownership pointers to unique_ptr and shared_ptr, in part because the underlying resource holder needs / uses the original ownership pointer (which is also a simple pointer). For example, a normal vector implementation contains one ownership pointer and two non-ownership pointers. Many ABI (essentially all C-oriented interfaces) use tweets, some of which have ownership. Because of the need to keep C compilable, some interfaces cannot simply add ownership (although this is a rare good use of macros, which simply expands to become ownership pointers in C++ mode).

Note (Note)

Owner does not contain any semantics beyond T*. It can be used without modifying any code and does not affect ABI. It is just an indication for programmers and analysis tools. For example, if owner is a member of a class, it's best to prepare a destructor to destroy it.

Example, bad (negative example)

Returning a (original) pointer increases the uncertainty of caller lifecycle management; that is, who should destroy the object the pointer points to?

Gadget* make_gadget (int n)

{

Auto p = new Gadget {n}

/ /...

Return p

}

Void caller (int n)

{

Auto p = make_gadget (n); / / remember to delete p

/ /...

Delete p

}

This code eliminates the pain from memory leaks, but adds false allocation and release operations and unnecessary verbosity. If the Gadget is easy to move out of the function (that is, very small or there is an efficient move operation), simply pass the value (refer to the "output" return value).

Gadget make_gadget (int n)

{

Gadget g {n}

/ /...

Return g

} Note (note)

This criterion applies to factory functions.

Note (Note)

If pointer semantics are required (for example, because the returned pointer needs to point to a base class (an interface) in the class hierarchy), return a smart pointer.

Enforcement (implementation recommendations)

(Simple) Warn on delete of a raw pointer that is not an owner.

(simple) warns against destroying raw pointers other than the owner type.

(Moderate) Warn on failure to either reset or explicitly delete an owner pointer on every code path.

(medium) issue a warning if the onwer pointer is not reset or destroyed on all code paths.

(Simple) Warn if the return value of new is assigned to a raw pointer.

(simple) issue a warning if the return value of new is assigned to the original pointer.

(Simple) Warn if a function returns an object that was allocated within the function but has a move constructor. Suggest considering returning it by value instead. 、

(simple) if the object returned by a function allocates memory within the function, but contains a mobile constructor. It is suggested to return by passing a value.

At this point, I believe you have a deeper understanding of "why the original pointer of C++ should not have ownership". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.