"delete" Frage

[David_pb]

Firefighter schrieb:

Ok alles klar, und der Dtor hat auch so seine richtigkeit, ja?

Ja!

[Firefighter]

Ok danke, hab ichs mir doch richtig vorgestellt.

[Firefighter]

std::vector<std::auto_ptr<Kontobewegung> > bewegungen;

Wenn ich das so gestalte(deklaration scheint noch fehlerhaft zu sein, da ich fehler bekomme) brauche ich mich später nicht über das aufräumem kümmern richtig`?

[David_pb]

Theoretisch hast du da recht!

[MFK]

Firefighter schrieb:

Wenn ich das so gestalte(deklaration scheint noch fehlerhaft zu sein, da ich fehler bekomme) brauche ich mich später nicht über das aufräumem kümmern richtig`?

Falsch. auto_ptr ist wegen seiner Kopiersemantik nicht für die Container der Standardbibliothek geeignet.

[Firefighter]

EDIT: Ok MFK ich danke dir, das erklärt einige Fehler.

Mit den shared_ptr, hab ich recht? aber mal ne andere Frage, wenn meine deklaration wie oben aussieht, wie könnte dann ein pushback eines möglichen kontobewegung-zeiger aussehen?Die Referenz ist mir dabei gerade nicht sehr hilfreich

[Fellhuhn]

Kontenbewegung *bestechung = new Kontenbewegung();
bewegungen.push_back(bestechung);

[Firefighter]

Öhmm...nee ich glaube das meinte ich nicht...sondern ich meinte eher, wie es mit shared_ptr ausehen müsste?Weil mit den burschen hab ich noch net so viel erfahrung.

[David_pb]

So?

bewegungen.push_back( shared_ptr<Kontenbewegung>( new Kontenbewegung() ) );

[Firefighter]

Ok das hilft mir schonmal weiter, und die Deklaration vom vector wäre dann so hier?:

std::vector< shared_ptr<Irgendwas> > vieles_irgendwas;

?

[David_pb]

Sieht ok aus.

[Firefighter]

Und auf die deklaration kann ich dein push_back anwenden? Kann doch eigentlich bei deinem push_back das führende shared<> zeugs weglassen und nur ein normales new machen oder nicht?

[Firefighter]

OK hat sich erledigt, habs alleine hinbekommen. Aber mal ne andere Frage, worin besteht nun der Underschied zwischen auto_ptr und shared_ptr?also aufjedenfall schonmal die Containerkompatiblität, und das shared_ptr sich ums aufräumen kümmert, aber was noch?

[Firefighter]

Ok hab mir auch das ebend selbst beantwortet, danke für eure Beiträge.

[Nexus]

Vielleicht kannst du dir auch mal Boost.Pointer Container anschauen, da werden die Zeiger auch automatisch freigegeben.

[Firefighter]

Alles klar Nexus, danke für den Hinweis, kannste eventuell kurz erklären wo der signifikanteste Unterschied liegt?

[Nexus]

Die Pointer-Container speichern intern gerade Zeiger (wie könnte es anders sein ;)). Es existieren die analogen Container zur STL, wie ptr_vector , ptr_deque , ptr_list etc.

Das führt zu verschiedenen Vorteilen für den Anwender:

• Die gespeicherten Elemente müssen im Gegensatz zu STL-Containern nicht kopierkonstruierbar oder zuweisbar sein.
• Bei Array-Containern wie boost::ptr_vector sind interne Operationen wie Löschungen und Einfügungen performanter, da nur Zeiger umgehängt werden.
• Die Indirektion entfällt beim Aufruf. Man kann direkt schreiben vec[1] oder vec.front() , anstatt dass man noch einmal dereferenzieren muss.

Siehe auch hier.

P.S. Die ersten beiden Punkte beziehen sich auf den Vergleich zu STL-Containern mit Objekten, der dritte zu STL-Containern mit Smart-Pointern.

[Firefighter]

Klasse, ich danke, das sind ja fabelhafte Geschichten.Haste super erklärt.

[hustbaer]

David_pb schrieb:

So?

bewegungen.push_back( shared_ptr<Kontenbewegung>( new Kontenbewegung() ) );

Das ist schlecht. Besser so:

shared_ptr<Kontenbewegung> kbw(new Kontenbewegung());
bewegungen.push_back(kbw);

Begründung bitte selbst in der Boost Doku nachlesen, danke.

[Firefighter]

Danke hustbaer, habs mir mal durchgelesen.Mir ist aber noch nicht ganz klar was das im Bezug auf mein Konstrukt ausmacht.Ich hab mir mal das Beispiel aus der Boost Doku durchgelesen:

void f(shared_ptr<int>, int);
int g();

void ok()
{
    shared_ptr<int> p(new int(2));
    f(p, g());
}

void bad()
{
    f(shared_ptr<int>(new int(2)), g());
}

Wenn ich das also richtig verstanden habe:

Since function arguments are evaluated in unspecified order, it is possible for new int(2) to be evaluated first, g() second, and we may never get to the shared_ptr constructor if g throws an exception

Das Funktionsargumente in keiner bestimmten Reihenfolge abgearbeitet werden können, und im Falle einer Exception wir niemals bei dem eigentlichen shared_ptr Konstrukt ankommen, ist das so richtig?Was bedeutet das aber in meinem Fall?

bewegungen.push_back( shared_ptr<Kontenbewegung>( new Kontenbewegung() ) );

Achso, es könnte also sein, das bei meiner erzeugung durch new eine Exception fliegt und ich dadurch nie bei shared_ptr ankomme?