Liegen lokale Klassen auf dem Stack?

[himitsu]

Wenn man unbedingt will, dann kann auch im Delphi eine Klasse auf den Stack.
Siehe NewInstance und FreeInstance, wo man die Speicherverwaltung ändern müsste.

Aber da ist es dann einfacher einen Record zu verwenden.

[Stevie]

Zitat von himitsu:

Wenn man unbedingt will, dann kann auch im Delphi eine Klasse auf den Stack.
Siehe NewInstance und FreeInstance, wo man die Speicherverwaltung ändern müsste.

Jo, genau und wenn sie nicht innerhalb der Routine wieder freigibst, zerschießt du dir den Stack, Klasse Idee

[himitsu]

Die ist doch lokal, also muß sie sowieso am Ende weg.
Automatisch freigegeben wird also so oder so der Speicher, aber Referenzen innerhalb der Klasse (z.B. Strings) schwirren dann als Speicherleck im Heap rum.

Wer unbedingt sowas machen will, der hat dann halt gefälligst auch bissl aufzupassen.

[Fritzew]

Es gab (oder gibt sogar noch) das gute alte object..... "TurboVision"
Also sowas wie

Delphi-Quellcode:

type tmyObject = object
end;

Das konnte man auf dem Stack benutzen.
Habe gerade eine Anwendung sortiert die das noch benutzt hat..
"Gute alte Zeit", Handbücher die einen halben Meter dick waren aufeinander gestapelt....

[QuickAndDirty]

Stack Allocation scheint ziemlich praktisch zu sein, besonders wenn man hunderte Objekte hat.
So liegen Beispielsweise alle Items eines VCL TStringgrids auf dem Stack. Die Struktur hinter Cells[col, row] und Objects[col, row] ist eine Objekt vom typ TStringGridStrings.
TStringGridStrings verschiebt einfach den Basepointer des Stacks wenn Collcount oder Rowcount erhöht werden.
Ist mit Stack Allocation das manipulieren des BP Registers gemeint gemeint? oder ist das wieder was anderes?

[Neutral General]

Zitat von QuickAndDirty:

So liegen Beispielsweise alle Items eines VCL TStringgrids auf dem Stack. Die Struktur hinter Cells[col, row] und Objects[col, row] ist eine Objekt vom typ TStringGridStrings.

Das ist unmöglich. Für Daten die auf dem Stack abgelegt werden gibt es nach der aktuell laufenden Prozedur keine Garantie dass diese nicht überschrieben werden.
Eher im Gegenteil: Die Daten werden mit ziemlicher Sicherheit früher oder später überschrieben.
Dazu kommt noch, dass man den Speicher auf dem Stack am Ende einer Prozedur freigeben muss oder man zerschießt sich den Stack. Das ist aus so vielen Gründen nicht möglich und Unsinn.

Lokale Variablen kann man durchaus auf dem Stack ablegen, auch ganze Objekte (wie man dazu steht ist natürlich ein anderes Thema ) aber nichts auf dem Stack überlebt den aktuellen Stackframe.

[Stevie]

Es geht in dem Blog zwar um C++ und Spieleentwicklung, aber die technischen Informationen lassen sich auch in Delphi übertragen:
http://ithare.com/c-for-games-perfor...data-locality/

BTW, jeder unnötige string (vor allem die impliziten, die man so gar nicht mitbekommt) ist auch eine Heapallokierung.
Von daher macht es schon Sinn, diesbezüglich ein bisschen Bescheid zu wissen und sensibel zu sein.

Anekdote: Ich habe jüngst einen Rot-Schwarz-Baum implementiert. Die ursprüngliche Implementierung nutzte für die Knoten Objekte.
Einfach zu implementieren und man konnte schön Vererbung nutzen (TRedBlackTreeNode<T> <- TRedBlackTreeNode <- TBinaryTreeNode).
Das sorgte allerdings für elendigen Speicheroverhead durch den ganzen Klump, der bei Objekten so mit kommt.
Also lieber Records/Pointer - erste Implementierung mit New/Dispose. Weniger Speicher - gut.
Aber über Zeit Memoryfragmentierung (übrigens genauso wie bei Objekten) und somit zunehmende Cache misses.
Also den Speicher für die Records aus einem Array nehmen, so dass eine bessere Lokalität gegeben ist.