std::vector mit unterschiedliche grossen Datentypen

[Swordfish]

@Bushmaster Und string mit SSO ist das größte was hinein kann und damit ist ein variant auch mindesten so groß. (und die Größe steht natürlich schon zur compiletime fest.)

[Ein ehemaliger Benutzer]

@Swordfish sagte in std::vector mit unterschiedliche grossen Datentypen:

@Bushmaster Und string mit SSO ist das größte was hinein kann und damit ist ein variant auch mindesten so groß. (und die Größe steht natürlich schon zur compiletime fest.)

du kannst recht haben. im realease-modus sind es 32 bytes, also nur 8 bytes weniger.

[Swordfish]

Dieser Beitrag wurde gelöscht!

[titan99_]

@wob sagte in std::vector mit unterschiedliche grossen Datentypen:

Natürlich sonst auch an virtual ~Foo denken

virtual dtor in der Basisklasse spielt aber nur eine Rolle, wenn abgeleitete Klassen einen Desktruktor implementiert haben, damit auch der Destruktor in der abgeleiteten Klasse aufgerufen wird? siehe stackoverflow.

Oder sollten Klassen, die einen dtor implementiert haben und von denen abgeleitet wird, immer virtual dtor haben?

[*john 0]

@titan99_ sagte in std::vector mit unterschiedliche grossen Datentypen:

Oder sollten Klassen, die einen dtor implementiert haben und von denen abgeleitet wird, immer virtual dtor haben?

Ja, sonst wird beim Löschen über den Basiszeiger nicht korrekt freigegeben bzw. nicht korrekt die Destruktoren der Member aufgerufen.

[hustbaer]

@titan99_ sagte in std::vector mit unterschiedliche grossen Datentypen:

Oder sollten Klassen, die einen dtor implementiert haben und von denen abgeleitet wird, immer virtual dtor haben?

Wenn die Objekte über Basisklassenzeiger gelöscht werden können, dann wäre es gut wenn der Dtor der Basisklasse virtual ist. Denn ob die abgeleitete Klasse einen Dtor hat oder nicht, das kann sich schnell mal ändern. Und der der das ändert, sieht nicht unbedingt ob der Dtor der Basisklasse virtual ist oder nicht.

[Ein ehemaliger Benutzer]

@hustbaer sagte in std::vector mit unterschiedliche grossen Datentypen:

Denn ob die abgeleitete Klasse einen Dtor hat oder nicht, das kann sich schnell mal ändern. Und der der das ändert, sieht nicht unbedingt ob der Dtor der Basisklasse virtual ist oder nicht.

Das Problem ist nicht, ob die abgeleitete Klasse einen (explizit geschriebenen) Destruktor hat. Wenn der Konstruktor der Basisklasse nicht virtual ist, werden Destruktoren der Member nicht ausgeführt:

#include <iostream>

struct Member
{
  ~Member() { std::cout << "Ich geh kaputt\n"; }
};
  
struct Base
{
  ~Base(){}
};

struct Derived : Base
{
  Member member;
};

int main()
{
  Base *b = new Derived;
  delete b;
}

gibt nichts aus.

[Swordfish]

@manni66 sagte in std::vector mit unterschiedliche grossen Datentypen:

werden Destruktoren der Member nicht ausgeführt:

Weil der Destructor von Derived nicht ausgeführt wird wenn ~Base nicht virtual ist. Mann.

[Ein ehemaliger Benutzer]

@Swordfish sagte in std::vector mit unterschiedliche grossen Datentypen:

@manni66 sagte in std::vector mit unterschiedliche grossen Datentypen:

werden Destruktoren der Member nicht ausgeführt:

Weil der Destructor von Derived nicht ausgeführt wird wenn ~Base nicht virtual ist. Mann.

Jaha - und was willst du damit sagen?

[Swordfish]

@manni66 Das habe ich mich ehrlich gesagt bei Deinem Post gefragt.

[Ein ehemaliger Benutzer]

@Swordfish sagte in std::vector mit unterschiedliche grossen Datentypen:

@manni66 Das habe ich mich ehrlich gesagt bei Deinem Post gefragt.

Vielleicht noch einmal lesen? Den zitierten auch?

[hustbaer]

@manni66 Ja stimmt, es geht darum ob der Dtor der abgeleiteten Klasse irgendwas interessantes macht - ob nun der selbst geschriebene Teil oder der Teil wo die Member zerstört werden. Und den Teil der die Member zerstört hat man natürlich automatisch sobald man Member mit nicht-trivialem Dtor hat - auch wenn man selbst keine Dtor-Definition hinschreibt.

[Swordfish]

@manni66 ah sorry, ja, kapiert.