Deconstructor being called to early

Question

I have a code with a class and objects. This objects recursively copy themselves (deep copy I hope) and yeah, do some recursive calculations.

However once I delete the inner content in the deconstructor it throws errors (line 29). I never call the deconstructor manually, and all objects are deep copies.. How does it come the deconstructor is somehow called(automatic?) while I still hold instances somehwere.
https://code.sololearn.com/cKjmasSYEddZ/?ref=app

Answer 1

The rule of 3 ( or 5 with the introduction of move ) states that if you implement any of the following:
destructor
copy constructor
copy assignment operator
( and in the case of rule of 5 )
move constructor
move assignment operator

Then you should implement all of them.
You have a destructor implemented so you should also implement the rest.

Currently you are copying Pos ( line 85: Temp=mydie.copy(); ) as well as in the visitAll 'mydie' parameter.
Without the copy constructor/assignment-operator C++ performs a shallow copy, aka the pointer itself is copied.

If you implement the other constructors/operators you can properly implement deep copy.

Because of the hassle of implementing all of these you may want to ask yourself if you really need to allocate memory.
I would recommend you to use std::array/std::vector instead to skip all of these steps.
( or just change int* die; to int die[6]; and remove the die = new int part )

Answer 2

Alexander Thiem The character limit is a good thing. It avoids people dumping walls of code into the question description, which is the wrong place for that.
The right way is to link from Code Playground, like you did. Better if you link into the question description, so it gets more visible and fixed.

Answer 3

c++ destructors are not supposed to have anything.
https://www.geeksforgeeks.org/destructors-c/

Answer 4

Dennis
yes, I was also thinking this is the hard way of doing something...
maybe there is a compelling reason to do it this way..
following this to see how it resolves.
Manually micro-managing stuff is something i'm not good at. Hoping to learn by watching at the sideline.

Answer 5

Thanks a lot for your helpDennis & Bob_Li .
And yeah, i should‘ve linked the code in the discription, but the character limit was already to small for the description itself:)

I see how the implicit copy in the function call does create a shallow copy.
But i rather like to keep full control over my code (or rather i dont like using anything that looks like a lybrary lol). Thats why i like to use simple pointers where i can and int[6] always feels limited to constants/ less controlleable. It might he the better solution though

Answer 6

Due to a character limit of 512????, i had to share the code here first, now i shortened the question so it fits there as well… imo linking a code should not count as using that many characters:
https://code.sololearn.com/cKjmasSYEddZ/?ref=app

I appreciate any explanations/hints/ideas even if they arent complete

Answer 7

Dennis Changing it to die[6] (and still deleting it in the deconstructor) still results in a error, so it seems to be a shallow copy as well.

The question would be (for the pointer solution as well as the [6] solution: is the deallocation automatically done once all objects referencing the array are deconstructed anyway?

Answer 8

C++ has no way to know if all objects referencing the array are destructed. There is no reference counting unless you use something like shared_ptr.

The correct way is that the array is copied from one struct instance to the other element by element so the old one can be deallocated together with the struct it is contained in