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 von himitsu:

Natürlich nicht.

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

[Neutral General]

Zitat von Namenloser:

Zitat von himitsu:

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 von Namenloser:

Zitat von himitsu:

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 von Neutral General:

Zitat von Namenloser:

Zitat von himitsu:

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 von Namenloser:

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 von Neutral General:

Zitat von Namenloser:

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 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.