C++ calls destructor immediately, even when rule of three is followed - c++

Question

Here is my following code. Once the constructor of A is complete, it immediately calls the ~B and deletes the allocated variable. I have the copy constructor and assignment constructor. Should I implement rule of five to prevent this?
EDIT: I have edited my copy and assignment constructor implementations, but still the destructor is being called.
class B
{
public:
C **table;
B()
{
table = new C *[TABLE_SIZE]();
}
B(const B& other)
{
table = new C *[TABLE_SIZE];
memcpy(table, other.table, sizeof(C *)* TABLE_SIZE);
}
B& operator = (const B& other)
{
if (this == &other)
{
return *this;
}
delete[] table;
table = new C *[TABLE_SIZE];
memcpy(table, other.table, sizeof(C *)* TABLE_SIZE);
return *this;
}
~B()
{
delete[] table;
}
}
class A
{
protected:
B funcA();
private:
B _b;
}
A::A()
{
this->_b = this->funcA();
// calls ~B here and destroys table
}

Answer 1

You do have the copy constructor and copy assignment operator implemented, but incorrectly. You implemented them to do exactly what the defaults do, which is of course wrong for your case of owning a dynamically allocated memory stored in a raw pointer. The Rule of Three of course means that you must implement them consistently.
In your case, this most likely means the copy operations must deep-copy the C object:
class B
{
public:
C *table;
B() : table(new C()) {}
B(const B& other) : table(new C(*other.table)) {}
B& operator = (const B& other)
{
if (this == &other)
{
return *this;
}
delete table;
table = new C(*other.table);
return *this;
}
~B()
{
delete table;
}
};
Notice that you default constructor wouldn't even compile - you were assigning a C* into a C**. I changed the code above to use a single allocation (and single-item delete) instead of an array. If you do have an array, the principle stays the same.
Of course, it's preferable to follow the Rule of Zero instead of the Rule of Three—use an appropriate smart pointer if possible. If your real use case is an array, that would be turning table into a std::vector<C>. Then you wouldn't have to supply the copy operations or destructor at all.
If you actually want to share one C among all copies of B, then you'll need to use an appropriate shared-ownership smart pointer instead, such as std::shared_ptr<C>.

Answer 2

Simply put, the temporary instance returned by funcA should be destroyed, that's normal and expected. The fact that your code is not functioning as a result means that your copy constructor and assignment operator are not functioning correctly.
But more fundamentally, you're violating several more important rules than the Rule of Three. You're failing to re-use the existing solution of std::vector. You're violating SRP by tying together memory management and whatever else B does when it's at home. You're failing to use RAII to manage your internal resources- a big exception safety fail.
Basically, the core problem is that you're even attempting to perform these operations. Don't. Just use std::vector<C*> and make the compiler and Standard library vendor implement them for you. They will save you a lot of code, and furthermore, they will be correct in ways that I'm going to guess that you don't know exist yet, like exception safety. The Rule of Three and the Rule of Five (which didn't even exist long enough to become a rule) are both vastly inferior to the Rule of Zero.
Here's B but implemented correctly:
class B {
public:
std::vector<C*> table;
B() : table(TABLE_SIZE) {}
};
Simple, ain't it?
As a side note, I don't know where you're getting your learning materials, but you should burn with fire any source so seriously outdated as to recommend self-assignment checks, and well, any of that code. May as well tell you that 640k of memory is all you'll ever need.

Answer 3

Your constructor is:
A::A()
{
this->_b = this->funcA();
// calls ~B here and destroys table
}
The comment is correct, although the table being destroyed is the table in the temporary object, not the table of _b. Since you fixed your copy-assignment operator this means that _b's table is fine.
The list of steps in executing this constructor is:
Call default constructor of _b
Call funcA, returning a temporary object of type B
Call _b 's assignment operator with that temporary object
Destruct the temporary object.
The constructor could be improved by supplying funcA() directly as initializer for _b, instead of first default-constructing _b then using its assignment operator. (But there is still a temporary object destruction).
There may also be another temporary object created and destroyed in the process of returning from the function, depending on your compiler settings. (usually there would not be).