Wann ist etwas auf dem Heap/Stack?
-
wie gesagt, ichv erweise auf das entsprechende kapitel in more effective c++...
-
Ich bin Regelungstechniker, der nun auch die Aufgaben der Programmierung für Signalprozessoren mitübernehmen soll, da in unserem kleinem Entwicklungsteam der Programmierer die Stelle gewechselt hat.
Muss ich mir bei eingebetteten Systemen auch keine Gedanken um den Stack machen?
-
Skym0sh0 schrieb:
um stack größen würde ich mir keine sorgen machen, solange man nicht statische arrays der größe xxxtausend macht, sollte das passen. für alles adnere gibt es die STL-Container
Kellerautomat schrieb:
Skym0sh0 schrieb:
wie man rauskriegt wo was liegt
Da gibts nix rauzukriegen. Die Regeln sind simpel und intuitiv.
achja?
pass auf, ich gebe deiner funktion ein objekt und deine funktion sagt mir ob heap oder stack. ok?http://www.codeproject.com/Articles/35206/Pointer-pointing-to-Stack-or-Heap :p
-
Zisko schrieb:
Muss ich mir bei eingebetteten Systemen auch keine Gedanken um den Stack machen?
Das ist die falsche Frage.
Es geht nicht um Stack vs Heap. Die wirkliche Frage ist die Lebenzeit eines Objektes.
Soll es weiter existieren wenn der Scope verlassen wird oder nicht. Und wenn ja, per Kopie oder das Original.Du kannst 100GB an Daten in einen std::string schreiben der auf dem Stack liegt ohne dass der Stack explodiert (genug VRAM vorausgesetzt ;)).
-
http://stackoverflow.com/questions/1350819/c-free-store-vs-heap
Mit den Begriffen ist das auch etwas verwirrend.Zu new/delete:
Google nach:
RAII
-
Zeus schrieb:
Skym0sh0 schrieb:
um stack größen würde ich mir keine sorgen machen, solange man nicht statische arrays der größe xxxtausend macht, sollte das passen. für alles adnere gibt es die STL-Container
Kellerautomat schrieb:
Skym0sh0 schrieb:
wie man rauskriegt wo was liegt
Da gibts nix rauzukriegen. Die Regeln sind simpel und intuitiv.
achja?
pass auf, ich gebe deiner funktion ein objekt und deine funktion sagt mir ob heap oder stack. ok?http://www.codeproject.com/Articles/35206/Pointer-pointing-to-Stack-or-Heap :p
ach weil das ja so plattformunabhängig ist
-
Skym0sh0 schrieb:
Zeus schrieb:
Skym0sh0 schrieb:
um stack größen würde ich mir keine sorgen machen, solange man nicht statische arrays der größe xxxtausend macht, sollte das passen. für alles adnere gibt es die STL-Container
Kellerautomat schrieb:
Skym0sh0 schrieb:
wie man rauskriegt wo was liegt
Da gibts nix rauzukriegen. Die Regeln sind simpel und intuitiv.
achja?
pass auf, ich gebe deiner funktion ein objekt und deine funktion sagt mir ob heap oder stack. ok?http://www.codeproject.com/Articles/35206/Pointer-pointing-to-Stack-or-Heap :p
ach weil das ja so plattformunabhängig ist
Das die Funktion gar inline assembler verwendet macht Sie letzten Endes nutzlos.
-
Sone schrieb:
Das die Funktion gar inline assembler verwendet macht Sie letzten Endes nutzlos.
Warum?
-
Sone schrieb:
...
OMG bitte halte endliche die Fresse. Das ist ja nicht mehr erträglich mit Dir...
-
Sone schrieb:
Skym0sh0 schrieb:
Zeus schrieb:
Skym0sh0 schrieb:
um stack größen würde ich mir keine sorgen machen, solange man nicht statische arrays der größe xxxtausend macht, sollte das passen. für alles adnere gibt es die STL-Container
Kellerautomat schrieb:
Skym0sh0 schrieb:
wie man rauskriegt wo was liegt
Da gibts nix rauzukriegen. Die Regeln sind simpel und intuitiv.
achja?
pass auf, ich gebe deiner funktion ein objekt und deine funktion sagt mir ob heap oder stack. ok?http://www.codeproject.com/Articles/35206/Pointer-pointing-to-Stack-or-Heap :p
ach weil das ja so plattformunabhängig ist
Das die Funktion gar inline assembler verwendet macht Sie letzten Endes nutzlos.Warum? Schauen ob ein Pointer auf dem Stack/Free-Store liegt ist eine low-level Sache und ASM kann da schon angebracht sein.
-
Skym0sh0 schrieb:
pass auf, ich gebe deiner funktion ein objekt und deine funktion sagt mir ob heap oder stack. ok?
Ganz einfach. Dort, wo der Caller es angelegt hat. Was war daran jetzt so schwer?
-
Ich weiß nicht, wer hier die ungenannte Frage beantwortet hat, ein gegebenes Objekt darauf zu überprüfen, ob es im Heap oder Stack liegt, ich möchte nur noch einmal betonen, dass das fern der Frage des TEs liegt und ich daher alle, die sich über genannte Frage ausgelassen haben, des Zeitüberflusses oder bestenfalls Rieseninteresses bzgl. des Themas bezichtigen muss.
PS: Solch eine Antwort zu verfassen steckt mich aber im Bezug auf meine Bezichtigung in die selbe Ecke.
-
otze schrieb:
Sone schrieb:
Das die Funktion gar inline assembler verwendet macht Sie letzten Endes nutzlos.
Warum?
Weil die Syntax für den Inline Assembler dann auch noch Implementation-Defined ist...
Klar ist nutzlos stark übertrieben, nur dass ich dann den Code noch an meinen Compiler anpassen muss kotzt mich sowas von an.
P.S.: Erst jetzt herausgefunden, das GAS ja plattformunabhängig ist. Doof geguckt.
-
Shade Of Mine schrieb:
Zisko schrieb:
Muss ich mir bei eingebetteten Systemen auch keine Gedanken um den Stack machen?
Das ist die falsche Frage.
Es geht nicht um Stack vs Heap. Die wirkliche Frage ist die Lebenzeit eines Objektes.
Soll es weiter existieren wenn der Scope verlassen wird oder nicht. Und wenn ja, per Kopie oder das Original.Du kannst 100GB an Daten in einen std::string schreiben der auf dem Stack liegt ohne dass der Stack explodiert (genug VRAM vorausgesetzt ;)).
OK, und jetzt versuch' mal ein 100GB grosses Array auf dem Stack anzulegen.
-
Da fällt mir ein, eigentlich stimmt das hier doch so nicht
Die Member einer Klasse befinden sich dort, wo sich die Instanz befindet.
Wenn ich einen vector ohne new erstelle, dann nutzt der doch trotzdem new/delete und somit ist das, was er so intern damit macht, auf dem Heap.
Also ist erstmal zwar alles auf dem Stack, was man ohne new/delete anlegt, aber new sorgt dafür, dass alles Weitergehende dann auf dem Heap liegt.
-
Eisflamme schrieb:
Da fällt mir ein, eigentlich stimmt das hier doch so nicht
Doch, definiert der Standard.
-
@Eisflamme
Ist jetzt die Frage wie man Member definiert.Wenn du nen Zeiger-Member hast, der auf etwas zeigt was mit new angelegt wurde, dann liegt der Zeiger dort wo auch das Objekt liegt. Das was mit new angelegt wurde liegt natürlich immer im Freestore (Heap).
Wenn man jetzt das woraus der Zeiger zeigt auch als "Member" ansehen will, dann stimmt deine Aussage. Wenn man nur den Zeiger als "Member" ansieht (die mMn. sinnvollere Definition), dann stimmt es dagegen dass Member immer dort liegen wo ihr Objekt liegt.
Und bei std::vector, std::string etc. ist es nicht anders. Im Endeffekt haben die auch nur irgendwo nen Zeiger der auf etwas zeigt was mit new angelegt wurde. D.h. das vector/string Member liegt sehrwohl dort wo das Objekt liegt, nicht aber der vom vector/string kontrollierte "Inhalt".
-
Verstehe, nach der Definition macht das dann wohl Sinn.
Und wenn man bedenkt, dass jeder durch RAII/RRID automatisch auf seine eigenen "Kinder" aufpasst, macht es dann wohl auch mehr Sinn diese Definition zu nutzen. Wobei sich ein mit new/delete oder Smartpointer kontrollierendes Objekt dann auch nicht mehr so viel von dem Stack verwendenden Objekt unterscheidet, wie ich finde (im Bezug auf die Begriffsdefinition von Member). Denkt man dann jedoch weiter, macht es eigentlich nie Sinn, dass ein Objekt mit Pointern arbeitet, wenn es alleinverantwortlich für die jeweiligen Objekte ist...Letztlich ist es aber egal, weil der Standard das letzte Wort hat.
-
Eisflamme schrieb:
Denkt man dann jedoch weiter, macht es eigentlich nie Sinn, dass ein Objekt mit Pointern arbeitet, wenn es alleinverantwortlich für die jeweiligen Objekte ist...
Doch, klar:
- Polymorphismus
- Verspätete Initialisierung (so lange man kein boost::optional o.Ä. hat, und es sich nicht selbst stricken will, was durchaus nicht trivial ist, braucht man dazu Zeiger)
- Arrays mit variabler Grösse
- Dinge die zu gross sind als dass man sie auf den Stack packen sollte
-
Okay, wenn man also doch nicht so weiterdenkt, dann ist der Unterschied zwischen Member- und Nicht-Member-Bezeichnung doch relativ dünn.
