2

If I do this:

class A {
    B* pointer01 = new B();
    C* pointer02 = new C();
}

do I have to do, in the destructor:

delete pointer01;
delete pointer02;

or not? I can't find anything on this.

Accumulator
  • 873
  • 1
  • 13
  • 34
  • 2
    They have to be deleted at some point. Whether it is on the destructor or somewhere else depends on what you want `A` for. – juanchopanza Feb 01 '16 at 00:43
  • @juanchopanza technically they don't have to be... depends whether you like memory leaks or not – M.M Feb 01 '16 at 02:26
  • @M.M No, it isn't restricted to memory leaks. It depends on whether the relevant destructors have side effects. – juanchopanza Feb 01 '16 at 07:05

3 Answers3

3

If you actually are going to use pointers and dynamically allocated objects, then yes, you definitely should delete them in your destructor (unless you are doing something really weird and your class is not the owner of those objects. If that is the case, stop it). You will also most likely need appropriate copy and assignment semantics, see The Rule of Three.

However, it would most certainly be easier and better to just use automatic objects instead:

class A {
    B b;
    C c;
};
Baum mit Augen
  • 49,044
  • 25
  • 144
  • 182
  • 3
    Easier and better? Maybe. Depends what the class does. It might not even be _possible_, let alone "easier and better". – Lightness Races in Orbit Feb 01 '16 at 00:50
  • @LightnessRacesinOrbit I feel like my *"most certainly be easier and better"* is appropriate. I mean, someone asking this question is pretty unlikely to be implementing `std::unique_ptr`, but even if he is, my first paragraph applies. – Baum mit Augen Feb 01 '16 at 00:56
  • A simple case of needing to rely on forward declarations is all it takes. Though I admit one would have to look at the NSDMIs in the OP's code as strictly pseudo-code for that to apply. – Lightness Races in Orbit Feb 01 '16 at 01:05
2

Yes, you have - basically every new needs a corresponding delete. But you can use smart-pointers (std::unique_ptr here) to make life easier.

Anedar
  • 4,235
  • 1
  • 23
  • 41
1

I think the other answers focus too much on what should one do, and good practices, while skipping the real answer altogether.

The answer is no. You are not required to do so. I don't think that there any place in the standard that says, one is required to have a delete for each new. (It would be nice to have a quotation, if that's not true, that would be a real answer too.)

However, certainly resource acquisition should be paired up with release. It's a very bad not do so. It is never a good idea, but doesn't make the program illegal.

I do agree with vsoftco's comment, that such a program is semantically incorrect, but I still think it would make a legal c++ code. (I don't know the standard by heart, and I couldn't find a place which states causing a memory leak or not pairing new with delete is illegal.)

luk32
  • 15,812
  • 38
  • 62
  • 1
    I disagree a bit with you, although I see what you mean. It's not syntactically incorrect to mandate the deletion of a pointer in a destructor, however it is semantically incorrect (even if you may delete the memory via a non-special member function). If you don't do it, think what happens when you throw an exception, which is latter caught. You end up leaking memory. – vsoftco Feb 01 '16 at 00:56
  • If all places allocated with `new` are not freed by `deleted` upon the exit point, then does the program results in UB? If so my answer is wrong, if not, it's right. My point is, from standard's point of view it's okey to leak. Maybe not, I would like to see a proper contradiction. I know that it might appear controversial, but technically it's right, unless the standard really says it's not. I know it's bad practice, but going against practices doesn't make code illegal. – luk32 Feb 01 '16 at 00:59
  • It can lead to UB, depending on the destructors of `A` and `B`. Also the drigs analogy isn't great. In many contexts you can't do drugs, but they are a good idea. – juanchopanza Feb 01 '16 at 01:00
  • No, the answer it's not wrong per se, and I didn't downvoted btw. That's why I said I disagree *a bit*. – vsoftco Feb 01 '16 at 01:00
  • 1
    @juanchopanza Removed the reference, I just wanted to strenghten the point. Acutally probably drugs are not a bad option in way more cases than not freeing your memory properly. BTW, could you elaborate, or show real example, where not freeing allocated memory leads to UB or makes program illegal. I stand by my point even at the expense of downvotes. – luk32 Feb 01 '16 at 01:03
  • @luk32 You may want to quote [this](http://stackoverflow.com/q/1978709/3093378), although I'm pretty sure OP is thinking about best practices and not standardese quirks of C++. – vsoftco Feb 01 '16 at 01:13
  • In addition, there's nothing in the C++ standard that says you can't have a garbage collector that is freeing the memory for you automatically. – Vaughn Cato Feb 01 '16 at 01:14
  • @luk32 And I think [this](http://stackoverflow.com/a/9921320/3093378) may be an example of UB. – vsoftco Feb 01 '16 at 01:20
  • @vsoftco It's says, it might lead to UB and gives a definition when it does so. This is why it's a bad idea not to do so. Also why would standard do such a circling around and not simply said each `new` has to be paired with a appropriate `delete`? Maybe it is legal, and there is a reason for it. Btw, there is another answer by James Kanze which supports my point http://stackoverflow.com/a/9921060/1133179, also good find of a duplicate question. – luk32 Feb 01 '16 at 01:41