Heap/Stack Frage

F98

Wieder eine Frage an die C++ Profis hier:

Wenn ich mir meinetwegen ein Struct definiere und innerhalb dieses Structes verschiedene Variablen verwende:

struct Test1
{
     int a;
     float b;
}

Was passiert mit a und b, wenn ich das Struct mit "new" erzeuge?

Kommen die auf den Stack oder auf den Heap?

Dravere

Dazu muss man wohl kein Profi sein.
Die Variablen a und b kommen auf den Heap. Jeglicher vom struct benötigter Speicher kommt bei einem normalen new auf den Heap.

Grüssli

Also ich finde nicht, das man dafür kein Profi sein muß. Ich finde die Frage sehr berechtigt und nicht unbedingt ohne genaue Kenntnisse beantwortbar.

BarnieGeroellheimer schrieb:

Also ich finde nicht, das man dafür kein Profi sein muß. Ich finde die Frage sehr berechtigt und nicht unbedingt ohne genaue Kenntnisse beantwortbar.

Ein Objekt wird nunmal als ganzes im Speicher abgelegt. Es kann nicht teilweise hier und teilweise da stehen. Somit würde ich es auch als sehr leicht einstufen.

cu André

und wo landet das hier?

struct tata
{
    int a;
    int b;
} intance;

Auf dem Heap oder dem Stack oder doch ->anderswo?

Skym0sh0

sollte auf dem stack sein...

camper

Kommt darauf an, wo es steht.
Lokal (= in einer Funktionsdefinition) : auf dem Stack, wenn davor kein static steht, sonst statisch
In einer Klassendefinition: als nicht-statischer Member ist es Teil des Objekts, zu dem es gehört und befindet sich folglich im gleichen Speicherbereich; als statischer Member hätte es statische Speicherdauer
Außerhalb eines Blocks (global bzw. auf Namensraumebene): statisch (weder Stack noch Heap)

Wobei anzumerken ist, dass das nur die gewöhnliche Implementation ist, nichts im Standard gebietet obiges Verhalten (zumal der Standard ohnehin solche Dinge wie Stack oder Heap gar nicht - oder nur sehr indirekt - einführt). Es ist zum Beispiel ohne Weiteres denkbar, dass ein Compiler automatische Objekte, die sehr groß sind, intern auf dem Heap ablegt und transparent indirekt anspricht, um Stackspeicher zu sparen. Bei einem Interpreter wiederum ist die Unterscheidung ohnehin nicht besonders nützlich.