Liegen lokale Klassen auf dem Stack?

[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:

Zitat von QuickAndDirty (Beitrag 1388271)

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 :P ) 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.