Der Speichermanager wirft mit Exceptions um sich, wenn er einen falschen Zeiger, der nicht ihm gehört, zum Freigeben bekommt, oder für's Ändern der Größe.
Und wenn das Programm auf einen "falschen" Typ trüft, der nicht zu seiner Umgebung gehört, dann können Adressen und gemeinsam genutzte Objekte ein schönes Chaos ergeben, was dann auch in netten Exceptions oder in netten fehlerhaften Speicherzugriffen (Buffer Overun und Co.) enden, was dann sofort oder erst später knallt, wenn der entsprechende zerschossene Speicher dann benutzt wird.
Delphi-Quellcode:
type
TMyClass =
class
FeldA: Integer;
// liegt im Speicher am Offset +A
FeldB: Integer;
// liegt im Speicher am Offset +B
procedure MachWasX;
virtual;
// Adresse liegt in der RTTI am Offset +X
procedure MachWasZ;
virtual;
// Adresse liegt in der RTTI am Offset +Y
end;
Im Prinzip kann Delphi nichtbenutztes entfernen und das wird dann garnicht erst einkompilert. (auch wenn das dank der neuen
RTTI nicht immer so ist ... ratet mal, warum die EXEn immer größer werden ... weil auch potentiell ungenutztes einkompiliert wird .... könnte ja sein, daß man via
RTTI drauf zugreift, aber da wäre es schöner, wenn mich Delphi vorher gefragt hätte und ich ihm explizit sage, was unbedingt mit rein muß, auch wenn keine Benutzung erkannt wird)
Die EXE greift nur auf FeldB und MachWasZ zu ... der Compiler/Linker läßt FeldA und MachWasX einfach weg.
Die
DLL haz zufällig alles benutzt und jetzt steht aber in der EXE das EXE.FeldB an der Speicherstelle von
DLL.FeldA, sowie MachWasZ steht abeim Offset X,
womit dann die
DLL auf die falschen Speicherbereiche/Adressen zugreift, wenn sie auf eine Objektinstanz zugreift, die von der EXE erstellt wurde. Und andersrum genauso.
Edit: Wäre es eigentlich auch möglich gleich den ganzen 'Block' also
Label1.Caption := ('Hallo')
in eine
DLL zu setzten?
Ja, aber nur wenn man ddie Zugehörigkeiten beachtet.