Should we delete a pointer that is not new / malloc by us?

Question

class ClassA { public: ClassA(ClassB *p) b(p){} ~ClassA(){delete b;} ClassB *b; }; 

Is such a design good?

Answer 1

All in all, this is a bad idea. Quite often, you simply don’t know how the ClassB object was created. It can be a pointer to an array element created using the new [] operator, or it can be passed to you from a separate dll that uses a specialized memory allocator. In those cases, using the delete operator to delete this pointer would be a serious mistake.

Answer 2

The answer depends on that. You must clearly indicate who is responsible for the lifetime of the facility.

ClassA also lacks a custom constructor and assignment operator, which can lead to undefined behavior. For example:

 ClassA object1( new ClassB() ); //object1 takes ownership of the object ClassA object2( object1 ); //object2 takes ownership of the same object // now first object2 is destroyed and deletes the object // then object1 is destroyed and double-delete happens 

so your example is probably not very good.

Answer 3

Do you mean:

 class ClassA { ClassB *b; public: ClassA(ClassB * p) {b = p;} ~ClassA() {delete b;} }; 

This is not a good design. The one who creates must be the one who removes.

Answer 4

Usually using pointers in such a situation is a poor design. In such a situation, smart pointers are your best friends. However, if you need to use pointers, just choose any method and carefully document it.

Answer 5

There is nothing wrong with this - technically, you transferred ownership of ClassB instead of an instance of ClassA when you created (that is, an instance of ClassB exists before ClassA is needed, but as soon as ClassA is created, it will become the owner of classB).

Regardless of whether it is a good design, it depends on the context in which it is applied. For example, does it make sense that ClassA gets ownership of ClassB? Should you use a smart pointer instead of a plain old pointer?

Answer 6

As others have said, it is preferable to avoid this situation by using smart pointers or by deleting an object at the same level that was created ... or not using pointers at all.

At the same time, I would not say that this is a bad design for transferring ownership of an object if you make it obvious to ClassA users in the documentation. I faced a similar situation when writing functions that take a pointer to an object and copy-construct it for their own use. Where necessary, I try to annotate these functions with the help of "parameter copy semantics" or something that tells the caller: "After I return, you can do what you want after my ... U I have my own copy. "

If you use raw pointers, I would consider it important to establish these types of call contracts.

Answer 7

Usually not, this is a confusing / inconsistent design (usually you want the corresponding new and delete occur at the same level). However, there are some exceptions; for example, smart pointers are provided with a raw pointer and then become owners of the object, so they are responsible for calling delete when it is no longer needed.