Heap oder Stack - Entscheidungshilfen?



  • Hallo zusammen,

    ich würde gerne einmal wissen, wann ihr eure membervariablen auf dem Stack und wann auf dem Heap instanziiert? Wie trefft ihr da eure Entscheidung?
    Beispiel:

    ich habe in einer klasse als member variable einen vector der mit "heap objekten" gefüllt wird, weil ich eine dynamische bindung haben möchte...
    Was gibt es noch für Gründe? Ist die größe eines Objektes auch ausschlaggebend?

    Vielen Dank und euch einen schönen Abend!

    Günther



  • also, aus meiner Sicht gibt es 3 Gründe für den Heap:

    1.: Dynamischer Speicher (Stack ist eben fest ;-))

    2.: Globale Verfügbarkeit
    -> ich kann keinen Zeiger auf lokale Objekte zurückgeben,
    einen Zeiger auf ein Objekt auf dem Heap schon

    3.: Polymorphie und Design Patterns
    -> sowas ist auch mit dem Stack nicht realisierbar

    evtl, gibt es noch mehr Gründe für den Heap, aber das ist erstmal, was mir so einfällt.
    meist ist die Verwendung ohnehin intuitiv :p

    MfG DrakoXP



  • kommt eigentlich drauf an, wie du das haben willst, also auf stack sollte eigentlich schneller sein, muss du nicht selber ums aufraeumen kuemmern, desto aber auch fuer manche faelle nicht geeignet, weil es nach funktionende wieder die variable nicht mehr exitiert, und wenn du noch mal auf die variable zugreifst, ergibt daraus fehler, auf heap kannst du nach funktionsende weiter zugreifen, weil sie auf der freien speicher liegt, und sie muss nach benutzen von hand freigegeben werden mit delete, desto ergib wieder problem, wenn man das vergisst.



  • GüntherF schrieb:

    ich würde gerne einmal wissen, wann ihr eure membervariablen auf dem Stack und wann auf dem Heap instanziiert?

    Du kannst Membervariablen weder auf dem Heap "instanzieren", noch auf dem Stack.
    Member sind Member. Die leben immer dort, wo das Objekt lebt, welches sie enthält.

    Davon abgesehen...

    Ist die größe eines Objektes auch ausschlaggebend?

    Klar spielt die Grösse eine Rolle. Ein Objekt/Array mit ein paar Megabyte bringst du auf den meisten Systemen einfach nicht auf dem Stack unter. Zumindest nicht, ohne dass speziell was dafür tust (z.B. dem Linker mitteilst, dass du in deinem Programm gerne Threads mit grösserem Stack haben willst).



  • Merk dir einfach: versuch so viel wie möglich in den Stack zu beziehen. Statischer Speicher ist schnell, und Fehler werden zur Compiler-Zeit bekannt. Dynamischer Speicher ist langsamer und kann lästige Runtime-Errors geben.
    Es gibt auch statische Stack-Polymorphie. Sachen wie Templates machen es mit NVI- bzw. pImpl-Idioms möglich, z.B. das Strategie-Pattern. (1 Objekt, nicht virtuelles Interface, statische Implementierung, selbe Klasse, unterschiedliche Implemtierung ---> schnell und runtime-sicher.)



  • DrakoXP schrieb:

    ...
    3.: Polymorphie und Design Patterns
    -> sowas ist auch mit dem Stack nicht realisierbar
    ...

    Das würde ich ein wenig präzisieren wollen.
    Was mit dem "Stack" nicht geht, ist eine "Objekterzeugung nach Typbestimmung zur Laufzeit" - das ist nicht gleichbedeutend mit "Polymorphie und Design Patterns". Man kann viel Polymorphie und Design Patterns auch mit dem "Stack" realisieren...
    (ich habe mal Stack apostrophiert, weil ich mir sicher bin, dass der Ausdruck zwar weitverbreitet aber nicht ganz korrekt ist - aber hier wollen wir mal nicht päpstlicher sein als Benedikt 😉 )

    Ich möchte das nur konkretisieren, um Trugschlüsse zu vermeiden wie
    - "Das ist auf dem Stack - das kann gar keine Polymorphie sein"
    - "Hmmm ich will Polymorphie machen - jetzt muss ich das irgendwie auf dem Stack machen"
    - ....

    Gruß,

    Simon2.




Log in to reply