C++ : wann Stack, wann Heap

mikey

Polymorphie ist mit auf dem Stack abgelegten Objekten nicht möglich, da muss man auf dem Heap erzeugen.

OhneName

Polymorphie hat mit Stack/Heap doch erstmal gar nichts zu tun. Gegenbeispiel Polymorpie ohne Heap:

#include <iostream>
class Base
{
  public:
    virtual void func() { std::cout << "Base" << std::endl; }
};
class Derived : public Base
{
  public:
    virtual void func() { std::cout << "Derived" << std::endl; }
};
int main()
{
  Base b;
  Derived d;
  Base* pb = &b;
  pb->func(); // gibt base aus
  pb = &d;
  pb->func(); // gibt derived auas
}

Ich weiß was du meintest, aber so pauschal ist die Aussage einfach nicht korrekt.

OhneName, kannst du bitte erläutern, was mikey meinte? Oder mikey selber, bitte?

Artchi

mikey schrieb:

Polymorphie ist mit auf dem Stack abgelegten Objekten nicht möglich, da muss man auf dem Heap erzeugen.

Wer hat denn das Gerücht damals blos in Umlauf gebracht? Hält sich anscheinend immer noch hartnäckig.

Das was du meinst, sind dynamisch erzeugte Objekte. Das hat aber mit Polymorphie nur indirekt was zu tun.

Th69

Ich kenne aber auch kein reales Projekt, bei dem polymorphe Objekte auf dem Stack gehalten werden. Sicherlich muß man sie nicht zwingend auf dem Heap erzeugen (beides ist einfach nur ein Teil des Hauptspeichers), aber Mischen sollte man es z.B. schon mal gar nicht (da man dann ja nicht mehr weiß, welches der Objekte man "deleten" muß und welche nicht - ich gehe mal davon aus, daß man polymorphe Objekte in einem Container (z.B. std::vector oder std::list) speichert).

Th69 schrieb:

ich gehe mal davon aus, daß man polymorphe Objekte in einem Container (z.B. std::vector oder std::list) speichert).

Was soll das jetzt für nen Zusammenhang haben?

Th69

Weil man üblicherweise Polymorphie erst bei einer Menge von Objekten anwendet und man sich nicht den Aufwand macht für ein einzelnes Objekt komplette Klassenhierarchien mit virtuellen Methoden zu erstellen -)
Und zum Speichern dieser Objekte (bzw. Zeiger auf diese Objekte!!!) eignen sich nun mal die STL-Container am besten, da man dann einfach eine Iterator-Schleife schreiben kann.

simon.gysi

Th69 schrieb:

Weil man üblicherweise Polymorphie erst bei einer Menge von Objekten anwendet und man sich nicht den Aufwand macht für ein einzelnes Objekt komplette Klassenhierarchien mit virtuellen Methoden zu erstellen -)
Und zum Speichern dieser Objekte (bzw. Zeiger auf diese Objekte!!!) eignen sich nun mal die STL-Container am besten, da man dann einfach eine Iterator-Schleife schreiben kann.

??? Das ist zusammenhangslos.

Artchi

Polymorphie hat doch nichts mit der Anzahl von Objekten zu tun. Polymorphie kann schon bei einem einzigen Objekt nützlich sein. Es geht um Dynamik eines Datentyps und nicht um Mengen. Sollen wir hier noch mal die OO-Basics durchgehen?

class A
{
    public:
     virtual void out() { cout << "A"; }
};

class B : public A
{
    public:
     virtual void out() { cout << "B"; }
};

void foo(A &a)
{
    a.out();
}

int main()
{
    A a;
    foo(a);

    B b;
    foo(b);
}

Wetten das foo sowohl A als auch B ausgibt? Und obwohl ich keine Container habe und keinen Heap benutzt habe, hat Polymorphie funktioniert.

Es ist jedoch richtig, das wenn ich an einer anderen Stelle, unabhängig vom Scope, ein dynamisches Objekt speichern will, ich den Heap benutzen muß. Aber das muß ich auch machen, wenn ich keine Polymorphie anwende.

akari schrieb:

ja der Stack ist in der Regel schneller als der Heap.

Gilt das nicht nur für das Erzeugen eines Objektes aufm Heap ? Der Zugriff sollte doch gleich schnell bei beiden sein !?

KasF schrieb:

Gilt das nicht nur für das Erzeugen eines Objektes aufm Heap ? Der Zugriff sollte doch gleich schnell bei beiden sein !?

bei heap-zugriffen brauchste indirektion (pointer oder sowas). das kann langsamer sein, muss aber nicht.