ich bereite mich gerade in C++ auf einiges vor und versuche mir besonders die Eigenheiten der Sprache anzueignen. Folgendes habe ich :

class myclass
{
  public: myclass(int aa);
          int geta();
  private:
          int a;
};

myclass::myclass(int aa)
:a(aa)
{
}

int myclass geta()
{
  return a;
}

typedef myclass * mytype;

int main(...)
{
  mytype mt = new myclass(1);
  vector<mytype> v;
  v.push_back(mt);
  cout << v.back()->geta() << endl;
}

Das Funktioniert soweit, wenn ich jetzt aber v.pop_back() machen würde, dann würde er doch nur den Zeiger freimachen und nicht den referenzierten Speicher oder? Wie kriege ich hier also den Speicher wieder frei?

Wenn du myclass nicht polymorph benutzen möchtest, macht es meistens mehr Sinn Kopien im vector<myclass> zu speichern. Ansonsten ist die Verwnedung von tr1::shared_ptr<myclass> in soclhen Fällen sehr praktisch.

std::vector<myclass>

benutzt?

Ansonsten habe ich mir gerade die shared_ptr Referenz mal angeschaut. In dem Beispiel wird ein Vector aus shared_ptr erzeugt. Das Prinzip ist klar, wäre das sorum dann besser?

kannst du die Speicherverwaltung nicht komplett dem vector überlassen indem du

C/C++ Code:
std::vector<myclass>

benutzt?

Hm, das geht tatsächlich. Ich hatte da einen Compilerfehler in Erinnerung. Allerdings wäre dann trotzdem wieder eine vollständige Kopie des Objekts im Vektor.

Also der Hauptgrund warum ich das so mache ist, das ich größere Listen von eigenen Klassen brauche. Da die Objekte sehr groß werden, wird doch eine direkte Kopie im Vektor mehr Zeit in Anspruch nehmen als wenn ich nur Pointer kopiere oder?

Hast du es ausprobiert? Und wenn würde ich zu den Pointer-Containern aus boost raten.

Marcel(Gast) schrieb:

Ansonsten habe ich mir gerade die shared_ptr Referenz mal angeschaut. In dem Beispiel wird ein Vector aus shared_ptr erzeugt. Das Prinzip ist klar, wäre das sorum dann besser?

NEIN. shared_ptr ist nicht schlecht, gerade wenn unklar ist, wer die Verwaltung über die Objekte übernimmt. Doch shared_ptr ist wegen seiner Referenzzählung auch der teuerste Smartpointer, und sollte nicht als Allheilmittel eingesetzt werden. Wenn du weißt, das die Verwaltung deiner Klassen nur in dieser Liste passiert, wären die oben genannten Containerklassen deutlich vorzuziehen.

Marcel(Gast) schrieb:

kannst du die Speicherverwaltung nicht komplett dem vector überlassen indem du

C/C++ Code:
std::vector<myclass>

benutzt?

Hm, das geht tatsächlich. Ich hatte da einen Compilerfehler in Erinnerung. Allerdings wäre dann trotzdem wieder eine vollständige Kopie des Objekts im Vektor.

Ja, nur verschätzt man sich leicht bei Performancefragen, und unterschätzt auch gerne den Aufwand von new/delete (gerade wenn es sich um sehr viele Objekte handelt). Was schneller ist, lässt sich nur am konkreten Beispiel prüfen.

In dem Beispiel wird ein Vector aus shared_ptr erzeugt. Das Prinzip ist klar, wäre das sorum dann besser?

Ja, solange shared_ptr anwendbar ist. Aufpassen muss man z.B. bei zyklischen Referenzen (wenn myclass selber shared_ptr zu anderen Instanzen von myclass hält).
Ansonsten kannst du auch versuchen die Objekte etwas leichtgewichtiger zu machen, indem du z.B. den großen Datenhaufen woanders speicherst, verwaltet durch myclass.

...shared_ptr... Aufpassen muss man z.B. bei zyklischen Referenzen (wenn myclass selber shared_ptr zu anderen Instanzen von myclass hält).

Hierfür gibt es weak_ptr (Ändert aber nichts daran, das man shared_ptr mit Bedacht einsetzen sollte [u.a. wegen seiner "Kosten"]

Hierfür gibt es weak_ptr (Ändert aber nichts daran, das man shared_ptr mit Bedacht einsetzen sollte [u.a. wegen seiner "Kosten"]

Beim shared_ptr von "Kosten" zu reden, finde ich in den meisten seiner Anwendungen übertrieben. Ich hab da auf jeden Fall noch nie 'Kosten' spüren können (was nicht heißt, dass es auch Anwendungen gibt, wo so eine Kleinigkeit wie ein Zähler einen Einfluss hat).

asc schrieb:

Hierfür gibt es weak_ptr (Ändert aber nichts daran, das man shared_ptr mit Bedacht einsetzen sollte [u.a. wegen seiner "Kosten"]

Beim shared_ptr von "Kosten" zu reden, finde ich in den meisten seiner Anwendungen übertrieben. Ich hab da auf jeden Fall noch nie 'Kosten' spüren können (was nicht heißt, dass es auch Anwendungen gibt, wo so eine Kleinigkeit wie ein Zähler einen Einfluss hat).

Du hast halt Allokationen und Spin Locks im Code.
Es summiert sich auf. Vorallem aber ist es unnötig, einfach die ptr-Container von boost nehmen und fertig - spart sogar Arbeit.

Ein großes Problem ist es nicht, aber Kleinvieh macht auch Mist.

Beim shared_ptr von "Kosten" zu reden, finde ich in den meisten seiner Anwendungen übertrieben.

...größere Listen...

Ich setze auch shared_ptr ein, aber es ist dennoch nicht immer die beste Wahl. So wenig wie man im Vorfeld optimieren sollte, sollte man im Vorfeld jegliches Umfeld ignorieren.

Sofern es ausschließlich um die Verwaltung einer Liste mit Zeigern geht, ist shared_ptr fehl am Platz. Sofern man den Zeiger an mehreren Orten braucht, und die Aufräumreihenfolge nicht sichergestellt ist, ist shared_ptr/weak_ptr eine gute Wahl.