Qobject has within it a list of children. Something like:
class QObject {
std::vector<QObject*> children;
QObject *parent;
};
The constructor basically stores the parent and adds the object to its list
QObjec(QObject *parent) : parent(parent) {
if (parent)
parent->children.push_back(this);
}
The magic stays in the destructor. He has to destroy all the children. That’s easy. But he has to take care if he is someone’s son, you need to remove yourself from his list to avoid one delete
double.
virtual ~QObject() {
if (parent)
parent->removeChild(this);
for (unsigned i=0; i<children.size(); ++i) {
delete children[i];
}
}
The destructor must be virtual, because at the time of invoking it we want it to be called the destructor of the correct class, and only of Qobject.
To remove yourself from the father’s list, something like this could be done:
QObject::removeChild(QObject *child) {
std::vector<QObject*>::iterator iter = std::remove(children.begin(), children.end(), child);
children.erase(iter, children.end());
}
I just don’t understand much yet what you mean by builder who doesn’t accept assignments.
What does it mean to "make a copy constructor that doesn’t accept assignment Operators"? I don’t understand.
– Guilherme Bernal
Object ObjetoB = ObjetoA
.– user2692
@Lucashenrique or vc allows copy construction or does not allow, there is no way to partially remove the build by copy functionality, disabling the syntax with
=
but at the same time allowing direct startupObject ObjetoB{ObjetoA}
. You may, as @Uilherme-Bernal did, have no copy constructor and have other constructors.– pepper_chico