J
Wenn du uns die Fehlermeldung nicht liefern kannst, koennen wir auch nur Kristallkugelmutmassungen betreiben; dass das Symptom aber bei Verwendung von Plain Pointers, welche unter Beruecksichtigung der Aussage, dass du sie wegen des Cleans durch uniques ersetzen wolltest, offensichtlich nicht freigegeben werden (bzw. die Objekte, auf die sie zeigen), klingt das ganze eher so, als wuerdest du noch auf schon zerstoerten Objekten arbeiten.
Dass ein explizites Clear da hilft, passt zwar nicht ganz, aber die Frage ist auch, was genau ein Object macht. Kann es sein, dass das im Destruktor noch an der Liste herumfummeln will (zumal die Variable auch noch public ist)?
Wie dem auch sei, koennte auch etwas in Richtung [c]static initialization order fiasco[/c]; du kannst nicht vorhersagen, in welcher Reihenfolge statische Klassenvariablen (nicht statische Variablen innerhalb von Funktionen) konstruiert und auch geloescht werden. Statische Klassenvariablen solltest du im Prinzip mit demselben Respekt wie globale Variabeln behandeln, anders gesagt: Nutze sie nicht, ausser du hast einen sehr sehr triftigen Grund.
Trotzdem waere es vielleicht hilfreich, wenn du mal versuchen koenntest, mit Debugger die Fehlermeldung zu kriegen.
Man koennte versuchen, die Variable in eine statische Funktion wegzukapseln (--> Initialisierungsreihenfolge definiert), allerdings schafft das dein vermutliches Designproblem nicht aus der Welt und ob es in deinem Falle was bringen wuerde, ist auch fraglich.
Wenn du in den Destruktoren der Objekte auf der Liste rumfummelst, die sich gerade selbst schon in der Zerstoerung befindet, kann nichts gutes bei rauskommen... unique_ptr sorgt dafuer, dass die Zerstoerung der Objekte ohne dein Zutun garantiert angestossen wird, er korrigiert nicht auf magische Weise einen Logikfehler im Destruktor
EDIT: Bei weiterem nachdenken erscheint mir ein Fehler beim Zerstoeren doch wesentlich wahrscheinlicher als SIOF.
