Liegen lokale Klassen auf dem Stack?

[Bjoerk]

Beispiel Test class:

Delphi-Quellcode:

procedure TSomeClass.DoSomeThing;
var
  Test: TTest;
begin
  try
    Test := TTest.Create; // <-
    ..
  finally
    Test.Free;
  end;
end;

[himitsu]

Natürlich nicht.

Nur die Variable für den Instanzzeiger liegt auf dem Stack. (also nur der Pointer)

[Neutral General]

Warum fragst du denn? Bin neugierig.

[Namenloser]

Zitat:

Zitat von himitsu (Beitrag 1388228)

Natürlich nicht.

Ist nicht so „natürlich“. In C++ geht das nämlich durchaus.

[Neutral General]

Zitat:

Zitat von Namenloser (Beitrag 1388234)

Zitat:

Zitat von himitsu (Beitrag 1388228)

Natürlich nicht.

Ist nicht so „natürlich“. In C++ geht das nämlich durchaus.

Und wo sonst noch? Und wer benutzt/macht das?
Ich denke C++ ist in der Hinsicht eher "unnatürlich".

[Stevie]

Zitat:

Zitat von Namenloser (Beitrag 1388234)

Zitat:

Zitat von himitsu (Beitrag 1388228)

Natürlich nicht.

Ist nicht so „natürlich“. In C++ geht das nämlich durchaus.

Jo, dann rufste aber nich new auf.

[Bjoerk]

Ok. Vielen Dank.

[Namenloser]

Zitat:

Zitat von Neutral General (Beitrag 1388237)

Zitat:

Zitat von Namenloser (Beitrag 1388234)

Zitat:

Zitat von himitsu (Beitrag 1388228)

Natürlich nicht.

Ist nicht so „natürlich“. In C++ geht das nämlich durchaus.

Und wo sonst noch? Und wer benutzt/macht das?
Ich denke C++ ist in der Hinsicht eher "unnatürlich".

Mir fällt unter den objektorientierten Sprachen nur C++ ein. Aber wenn man in nicht-objektorientierten Sprachen objektorientiert programmiert, ist das gar nicht ungewöhnlich. Records liegen in Delphi ja auch auf dem Stack.

Wer das benutzt: Ich benutze das so oft es geht, weil Stack-Allokationen schneller sind als Heap-Allokationen. Sehr nützliches Feature meiner Meinung nach. Es geht dabei ja nicht nur um den Stack, sondern auch um geschachtelte Konstrukte, also beispielsweise Objekte, die wieder andere Objekte enthalten. Hier muss man nur einmal Speicher reservieren statt mehrfach und spart sich eine ganze Reihe von Pointern.

[Neutral General]

Zitat:

Zitat von Namenloser (Beitrag 1388240)

Wer das benutzt: Ich benutze das so oft es geht, weil Stack-Allokationen schneller sind als Heap-Allokationen. Sehr nützliches Feature meiner Meinung nach. Es geht dabei ja nicht nur um den Stack, sondern auch um geschachtelte Konstrukte, also beispielsweise Objekte, die wieder andere Objekte enthalten. Hier muss man nur einmal Speicher reservieren statt mehrfach und spart sich eine ganze Reihe von Pointern.

In meinen Augen ist der Stack nicht dazu gedacht dort komplette komplexe Objekte abzulegen.
Das kann je nachdem auch ganz schnell in die Hose gehen bei Rekursionen oder einer großen Menge Objekte.
Der Stack ist im Vergleich zum Heap winzig.

[Zacherl]

Zitat:

Zitat von Neutral General (Beitrag 1388243)

Zitat:

Zitat von Namenloser (Beitrag 1388240)

Wer das benutzt: Ich benutze das so oft es geht, weil Stack-Allokationen schneller sind als Heap-Allokationen. Sehr nützliches Feature meiner Meinung nach. Es geht dabei ja nicht nur um den Stack, sondern auch um geschachtelte Konstrukte, also beispielsweise Objekte, die wieder andere Objekte enthalten. Hier muss man nur einmal Speicher reservieren statt mehrfach und spart sich eine ganze Reihe von Pointern.

In meinen Augen ist der Stack nicht dazu gedacht dort komplette komplexe Objekte abzulegen.

Ansichtssache :P Ich sehe das wie Namenloser. Die Performance ist deutlich besser und in C++ ist das Konzept durchaus schlüssig, wenn man andere Kriteren wie RAII, Referenzen, Copy & Move Semantics miteinbezieht. Man kann natürlich auch jederzeit Objekte auf dem Heap anlegen, wenn man die Befürchtung hat, dass der Stack zu klein ist - macht man allerdings nur in Ausnahmefällen oder bei Containerklassen.