class EineKlasse
{
}

class Test
{
   private:
       std::vector<EineKlasse*> zeigers;

  public:
    void einefunktion(int wert)
    {
        for(int i =0;i<wert;i++)
        {
            zeigers.push_back(new EineKlasse);
        }
    }
  ~Test()
   {
       //muss ich hier wieder jedes element im vector abbräumen? ála
       for(int i =0;i<zeigers.size();i++)
       {
           delete zeigers[i];
       }
    }

};

Muss ich wie oben beschrieben, die Elemente nach dem "Gesetzt: Für jedes new ein delete" auch so wieder abräumen? Oder übernimmt das der Vector für mich?

...
Muss ich wie oben beschrieben, die Elemente nach dem "Gesetzt: Für jedes new ein delete" auch so wieder abräumen? ...

Ja.

Firefighter schrieb:

...
Oder übernimmt das der Vector für mich?

Nein.
Der vector destruiert nur die Objekt, die sich in ihm befinden ... in diesem Fall Zeiger.

Gruß,

Simon2.

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

Ja!

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`?

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.

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

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

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

?

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.

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.

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?

1. Fehler bei der Speicherallokation. Der Konstruktor des Objektes wird daher nie aufgerufen, alles paletti (außer dass du ohne Speicher schlecht dastehst)

2. Fehler im Ctor, dann werden die bereits konstruierten Teilobjekte wieder zerstört, die Exception fliegt und auch wieder kein Speicherleck - vorausgesetzt der Ctor ist exceptionsicher implementiert.

Du kriegst durch ne Exception beim new also keine Speicherlecks
Von der Exceptionsicherheit her kann man es also eigentlich als Einzeiler machen, wenns sich nur um einparametrige Funktionen handelt. Ob man sich das angewöhnen sollte und dann bei mehrparametrigen Funktionen immer dran denkt, es anders zu machen ist denke ich Geschmackssache. wirklich konsistent wäre es aber wohl nicht.

1. Fehler bei der Speicherallokation. Der Konstruktor des Objektes wird daher nie aufgerufen, alles paletti (außer dass du ohne Speicher schlecht dastehst)

Heißt das also, es kann passieren, das ich einen Null-Pointer in den Vector pushe, wenn dein Fall auftritt, und wird das push_back bei einem nicht-aufruf des Ctors abbgebrochen, wohl eher nicht,ne?