std::list problem
-
Hi,
ich versuche, eine Liste von Objekten zu erstellen, die alle interne membervariablen haben, die pointer sind. wenn ich mit push_back diese in die liste gebe, gehen aus irgendeinem grund alle pointer verloren/zeigen nicht mehr auf den richtigen wert. woran kann das liegen?
code:
std::list<Node> children;
....
children.push_back(child);Node klasse:
class Node {
...
protected:
BoundSphere<T> *sphere;
...
}lg
-
du hast vermutlich keinen passenden CopyCtor erstellt
-
nein, daran kanns nicht liegen, da ich mit dem debugger alles durchgegangen bin und das child korrekt kopiert wird (es gibt dafür einen copy constructor, wo alle werte kopiert und neue pointer erstellt werden) und sobald das child dann in der liste steht (nach dem durchgehen des copy constr.), sind die pointer falsch.
-
Der Fehler liegt aber in deinem Code, denn ich bezweifle, dass so ein gravierender Bug in deiner STL Implementierung noch niemandem aufgefallen ist
du kannst ja mit dem debugger durchgehen und bei jedem schritt die werte überprüfen - irgendwann müssen sie sich ändern, und dann hast du die relevante stelle gefunden. dann sollte es leicht gehen, den fehler zu finden.
-
tja, das hab ich ja versucht, aber es wird der copy constructor durchgegangen, der folgendermaßen ausschaut:
Node(const Node &node) {
parent = new Node();
this->setParent(node.parent);
sphere = new BoundSphere<T>(*(node.sphere));
}sowohl sphere als auch parent sind pointer. der copy constructor scheint gut zu funktionieren, das this object hat am ende alle pointer, die auf den richtigen wert zeigen. wird aber der copy constructor verlassen und zum push_back zurückgegangen, passen die pointer in der list nicht mehr. passt da was am copy constructor nicht?
lg
-
zeig mal dein operator=
hast du was über smart pointers gehört?
-
wo brauch ich da ein operator=? vielleicht liegts ja daran, die hab ich bis jetzt nicht implementiert...
-
23.1 Container requirements
3. The type of objects stored in these components shall meet the requirements of CopyConstructible(20.1.3) and the additional requirements of Assignable types(23.1.4)
-
tja, hab ich jetzt dazugegeben, der operator= wird aber nie aufgerufen also daran kann (zumindest das momentane problem) nicht liegen.
-
zeig mal setParent && destructor