std::vector mit unterschiedliche grossen Datentypen

[Ein ehemaliger Benutzer]

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

Also im Moment frage ich mich, für was es dann upcasting und downcasting gibt. Also ich bin am überlegen, einen std::vector mit smart_pointern zu verwenden, oder können dann auch Daten verloren gehen?

Mit Smart Pointern kannst du das Problem umgehen.

[Ein ehemaliger Benutzer]

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

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

weiss nicht ob das sinnvoll ist,

Nein. std::variant.

die idee hatte schon jemand; https://en.cppreference.com/w/cpp/utility/variant

The class template std::variant represents a type-safe union.

wurde aber erst 2017 umgesetzt.

[Swordfish]

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

Mit Smart Pointern kannst du das Problem umgehen.

Quatsch. Das hat nix mit smarten Pointern zu tun sondern mit Laufzeitpolymorphie. Und das geht eben definitionsgemäß nur wenn man Referenzen (Pointer oder Referenzen) auf die verschiedenen Objekte hat. Man darf diese Pointer dann unter gewissen umstänten casten.

[Ein ehemaliger Benutzer]

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

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

weiss nicht ob das sinnvoll ist,

Nein. std::variant.

variant ist cool. visual studio kennt es, nachdem c++17 in den compiler settings aktiviert wurde.

    int main()
    {
        variant<int, double, char, long, string, char*> v;
        
        cout << sizeof(v) << endl;  // 40 bytes wtf?

        v = 1234;
        auto val = get_if<int>(&v);
        cout << typeid(*val).name() << ": " << *val << endl;;

        v = 1234.5678;
        auto val2 = get_if<double>(&v);
        cout << typeid(*val2).name() << ": " << *val2 << endl;;
    }

bisschen viel overhead, aber das liegt wohl daran weil ich für debug compiliert habe.

[Mechanics]

Eher wegen dem string und SSO.

[Ein ehemaliger Benutzer]

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

Eher wegen dem string und SSO.

aber ich tue keinen string rein. die typenliste gibt doch nur an, was hinein darf.

[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.