In Which Situations To Delete A Pointer

Question

My following question is on memory management. I have for example an int variable not allocated dynamically in a class, let\'s say invar1. And I\'m passing the memory addres

Answer 1

You don't currently delete this int, or show where it's allocated. If neither object is supposed to own its parameter, I'd write

struct ex1 {
    ex1(int &i_) : i(i_) {}
    int &i;               // reference implies no ownership
};
struct ex2 {
    ex2(ex1 &e_) : e(e_) {}
    ex1 &e;               // reference implies no ownership
};

int i = 42;
ex1 a(i);
ex2 b(a);

If either argument is supposed to be owned by the new object, pass it as a unique_ptr. If either argument is supposed to be shared, use shared_ptr. I'd generally prefer any of these (reference or smart pointer) to raw pointers, because they give more information about your intentions.

---

In general, to make these decisions,

Should I delete ptoint?

is the wrong question. First consider things at a slightly higher level:

1. what does this int represent in your program?
2. who, if anyone, owns it?
3. how long is it supposed to live, compared to these classes that use it?

and then see how the answer falls out naturally for these examples:

• this int is an I/O mapped control register.

  In this case it wasn't created with new (it exists outside your whole program), and therefore you certainly shouldn't delete it. It should probably also be marked volatile, but that doesn't affect lifetime.

  Maybe something outside your class mapped the address and should also unmap it, which is loosely analogous to (de)allocating it, or maybe it's simply a well-known address.

• this int is a global logging level.

  In this case it presumably has either static lifetime, in which case no-one owns it, it was not explicitly allocated and therefore should not be explicitly de-allocated

  or, it's owned by a logger object/singleton/mock/whatever, and that object is responsible for deallocating it if necessary

• this int is being explicitly given to your object to own

  In this case, it's good practice to make that obvious, eg.

  ex1::ex1(std::unique_ptr<int> &&p) : m_p(std::move(p)) {}
  

  Note that making your local data member a unique_ptr or similar, also takes care of the lifetime automatically with no effort on your part.

• this int is being given to your object to use, but other objects may also be using it, and it isn't obvious which order they will finish in.

  Use a shared_ptr<int> instead of unique_ptr to describe this relationship. Again, the smart pointer will manage the lifetime for you.

In general, if you can encode the ownership and lifetime information in the type, you don't need to remember where to manually allocate and deallocate things. This is much clearer and safer.

If you can't encode that information in the type, you can at least be clear about your intentions: the fact that you ask about deallocation without mentioning lifetime or ownership, suggests you're working at the wrong level of abstraction.

Answer 2

just an appendix to the other answers

You can get rid of raw pointers and forget about memory management with the help of smart pointers (shared_ptr, unique_ptr).

The smart pointer is responsible for releasing the memory when it goes out of scope.

Here is an example:

#include <iostream>
#include <memory>

class ex1{
public:
    ex1(std::shared_ptr<int> p_intvar1)
    {
        ptoint = p_intvar1;
        std::cout << __func__ << std::endl;
    }
    
    ~ex1()
    {
        std::cout << __func__ << std::endl;
    }
private:
    std::shared_ptr<int> ptoint;
};

int main()
{
    std::shared_ptr<int> pi(new int(42));
    std::shared_ptr<ex1> objtoclass(new ex1(pi));

    /* 
     * when the main function returns, these smart pointers will go
     * go out of scope and delete the dynamically allocated memory
     */ 

    return 0;
}

Output:

ex1
~ex1

Answer 3

Because it has the address of an undynamically allocated int, I thought I don't need to delete it.

That is correct. Simply do not delete it.

The second part of your question was about dynamically allocated memory. Here you have to think a little more and make some decisions.

Lets say that your class called ex1 receives a raw pointer in its constructor for a memory that was dynamically allocated outside the class.

You, as the designer of the class, have to decide if this constructor "takes the ownership" of this pointer or not. If it does, then ex1 is responsible for deleting its memory and you should do it probably on the class destructor:

class ex1 {
public:
    /**
     * Warning: This constructor takes the ownership of p_intvar1,
     * which means you must not delete it somewhere else.
     */
    ex1(int* p_intvar1)
    {
        ptoint = p_intvar1;
    }

    ~ex1()
    {
        delete ptoint;
    }

    int* ptoint;
};

However, this is generally a bad design decision. You have to root for the user of this class read the commentary on the constructor and remember to not delete the memory allocated somewhere outside class ex1.

A method (or a constructor) that receives a pointer and takes its ownership is called "sink".

Someone would use this class like:

int* myInteger = new int(1);
ex1 obj(myInteger); // sink: obj takes the ownership of myInteger
// never delete myInteger outside ex1

Another approach is to say your class ex1 does not take the ownership, and whoever allocates memory for that pointer is the responsible for deleting it. Class ex1 must not delete anything on its destructor, and it should be used like this:

int* myInteger = new int(1);
ex1 obj(myInteger);
// use obj here
delete myInteger; // remeber to delete myInteger

Again, the user of your class must read some documentation in order to know that he is the responsible for deleting the stuff.

You have to choose between these two design decisions if you do not use modern C++.

In modern C++ (C++ 11 and 14) you can make things explicit in the code (i.e., do not have to rely only on code documentation).

First, in modern C++ you avoid using raw pointers. You have to choose between two kinds of "smart pointers": unique_ptr or shared_ptr. The difference between them is about ownership.

As their names say, an unique pointer is owned by only one guy, while a shared pointer can be owned by one or more (the ownership is shared).

An unique pointer (std::unique_ptr) cannot be copied, only "moved" from one place to another. If a class has an unique pointer as attribute, it is explicit that this class has the ownership of that pointer. If a method receives an unique pointer as copy, it is explicit that it is a "sink" method (takes the ownership of the pointer).

Your class ex1 could be written like this:

class ex1 {
public:
    ex1(std::unique_ptr<int> p_intvar1)
    {
        ptoint = std::move(p_intvar1);
    }

    std::unique_ptr<int> ptoint;
};

The user of this class should use it like:

auto myInteger = std::make_unique<int>(1);
ex1 obj(std::move(myInteger)); // sink
// here, myInteger is nullptr (it was moved to ex1 constructor)

If you forget to do "std::move" in the code above, the compiler will generate an error telling you that unique_ptr is not copyable.

Also note that you never have to delete memory explicitly. Smart pointers handle that for you.

Answer 4

Should I delete obj when I'm already deleting objtoclass?

Well you could but mind that deleting the same object twice is undefined behaviour and should be avoided. This can happen for example if you have two pointers for example pointing at same object, and you delete the original object using one pointer - then you should not delete that memory using another pointer also. In your situation you might as well end up with two pointers pointing to the same object.

In general, to build a class which manages memory internally (like you do seemingly), isn't trivial and you have to account for things like rule of three, etc.

Regarding that one should delete dynamically allocated memory you are right. You should not delete memory if it was not allocated dynamically.

PS. In order to avoid complications like above you can use smart pointers.

Answer 5

Because it has the address of an undynamically allocated int I thought I don't need to delete it.

Correct.

Should I delete obj when I'm already deleting objtoclass?

No.

Recall that you're not actually deleting pointers; you're using pointers to delete the thing they point to. As such, if you wrote both delete obj and delete objtoclass, because both pointers point to the same object, you'd be deleting that object twice.

I would caution you that this is a very easy mistake to make with your ex2 class, in which the ownership semantics of that pointed-to object are not entirely clear. You might consider using a smart pointer implementation to remove risk.