Wenn ich während der laufzeit ausdrücke auswerten möchte, sagt mir delphi immer : " Auf Variable 'recordno' kann wegen Optimierung nicht zugegriffen werden"

Warum dieses? Und wie kann ich die Variablen auswerten?

Könntest Du etwas mehr Quelltext posten? Dann können wir Dir besser helfen!

MfG
Peter

Taladan hat folgendes geschrieben:

Warum dieses? Und wie kann ich die Variablen auswerten?

Weil du die Code-Optimierung aktiv hast.

Die ist doch standardmäßig aktiv, oder? Ich hatte diese Fehlermeldung trotz Otimierung noch nie. Deswegen wäre es ganz gut, wenn er mal ein bisschen Code postet.

Bei meinen Debug-Orgien, bekomme ich das regelmäßig. Aber wenn man weiß, in welchem Register sich die Daten aufhalten (lernt man mit der Zeit), kann man das umgehen.

die optimierung kann man unter projekt - optionen - compiler ausschalten.

manchmal hilft es auch noch was, wenn man statt nur mit der maus über die variable zu fahren, die rechte maustaste drückt, und in dem menü dann auf fehlersuche - auswerten/ändern klickt, manchmal hat man da noch glück.

ach ja, nachdem man die optimierung ausgemacht hat, muss man manchmal delphi neu starten, damit es funktioniert.

Ich denke, es stimmt etwas am Quelltext nicht, wenn es nur mit ausgeschalteter Optimierung funktioniert. Und die Optimierung hat ja auch durchaus ihren Sinn und sollte nicht einfach so abgeschaltet werden. Es könnte sogar sein, dass die Variable wegoptimiert wurde und dann sollte man wirklich den Quelltext prüfen, ob man nicht irgendwo einen Fehler gemacht hat.

das seh ich anders, einen fehler im quellcode sieht man an den
warnungen (variable x wurde deklariert, aber nicht verwendet, oder
auf variable x zugewiesener wert wird nicht verwendent usw.)

ich denke die optimierung hat wirklich nur etwas mit dem speed des
progs zu tun, und ich hab noch nie das bedürfniss gehabt, dass irgend-
etwas schneller gehen müsste. also ich hab die optimierung schon
jahrelang aus, hatte noch nie probleme.

Es geht mir nicht um einen Fehler im Quellcode. Du kannst einen völlig fehlerfreien Code programmieren, der eine grauenhafte Performanz aufweist. Zum Beispiel ist BubbleSort ein fehlerfreier Code aber verwenden würde ich ihn trotzdem nicht.

Die Quellcode-Optimierung von Delphi wird sich schon etwas dabei denken, wenn eine Variable wegoptimiert wird (was ja immer noch nur eine Vermutung von mir ist, weshalb ich gerne mehr von dem Code sehen möchte.). Und wenn eine Variable tatsächlich wegoptimiert wird, dann sollte sich auch der Programmierer fragen, ob er ohne diese auskommen kann. Höchstwahrscheinlich wird das dann auch der Fall sein.

Ich für meinen Teil finde, dass ein Programmierer nicht nur ein funktionierendes Programm abliefern sollte, sondern auch eines, welches schonend mit den Resourcen des Rechners umgeht. Im privaten Bereich bei kleinen Shareware-Programmen mag das nicht so wichtig sein, jedoch in Wirtschaft und Wissenschaft ist das nicht mehr wegzudenken. In der Wirtschaft, weil Resourcen da richtig ins Geld gehen und in der Wissenschaft weil die Berechnungen dort enorm aufwändig sind und kleine Optimierungen schon Stunden weniger an Rechenzeit bedeuten können.
Selbst bei den kleinen Programmen, die ich schreibe, bin ich schon auf Optimierungsmöglichkeiten gestoßen, welche Aktionen von 30 Sekunden auf eine Sekunde reduzieren konnte.

Peter Lustig hat folgendes geschrieben:

Die Quellcode-Optimierung von Delphi wird sich schon etwas dabei denken, wenn eine Variable wegoptimiert wird

Von "wegoptimieren" kann nicht die Rede sein. Eher von Auslagern in CPU Registern.

Zitat:

Und wenn eine Variable tatsächlich wegoptimiert wird, dann sollte sich auch der Programmierer fragen, ob er ohne diese auskommen kann.

Du solltest bedenken das die CPU auch noch ein paar Allzweckregister hat, die als Variablen dienen können. Delphi nutzt davon mindestens 3 (macht 3 Vier-Byte Variablen).
Der Code-Optimierer lässt auch mal eine Schleife rückwärts laufen, auch wenn sie vorwärts Programmiert wurde. Und vor allem bei for-Schleifen kann die Optimierung den Code stark verändern. Die Zählvariable wird ins ECX Register auslagert, womit die Zählvariable als "Ausdruck kann nicht ausgewertet werden" gekennzeichnet ist. Sie steht ja im ECX Register und nicht mehr auf dem Speicherplatz der Variable. Und wenn der Code-Optimierer feststellt, dass eine lokale Variable während ihrem gesamten Gültigkeitsbereich im CPU Registern gehalten werden kann, dann reserviert auch keinen Stack dafür. Als Programmierer muss man aber diese Variable deklarieren, weil man sie mit Namen ansprechen muss. Die alternative wäre, wenn der Programmierer genau weiß, in welchem Register sich die Variable gerade aufhält, was ich mir nicht vorstellen kann. Das Compiler hingegen weiß ganz genau in welchem Register sich die "wegoptimierte" Variable befindet.

Zitat:

kleine Optimierungen schon Stunden weniger an Rechenzeit bedeuten können.

Da hatte ich mal einen Fall mit meinem ehemaligen Info-Lehrer. Gerade beim Bubblesort wollte ich nach jedem Durchgang die Schleife um 1 Element weniger durchlaufen lassen. Seine Argumentation zu meinem Geschwindigkeitsgewinn war, dass es bei solchen langwierigen Verfahren, die mehr als 2 Jahre brauchen, nicht auf die Zeit ankomme. Als ich dann sagte, dass es doch besser wäre wenn man sein Ergebnis in 1 Jahr hat, anstatt 2 Jahre zu warten, behaarte er auf seiner Aussage und begann ein anderes Thema.

Du scheinst Dich, was das angeht sehr viel besser damit auszukennen als ich, deswegen werde ich das von Dir geschrieben mal bei mir als "wieder was dazugelernt" verbuchen. Aber eine Anmerkung habe ich dann doch noch:

Zitat:

Und wenn der Code-Optimierer feststellt, dass eine lokale Variable während ihrem gesamten Gültigkeitsbereich im CPU Registern gehalten werden kann, dann reserviert auch keinen Stack dafür.

Genau das kann doch aber nicht sein, wenn Taladan darauf zugreifen will!

Info-Lehrer: autsch. Übel. Das MPI für Astrophysik hat letztens eine Simulation zur Supernova-Theorie mit - und jetzt halte Dich fest - mehreren hundertausend Billionen Rechenoperationen durchgeführt. Wenn Dein Informatiklehrer da am Werk gewesen wäre, wären die wahrscheinlich in hundert Jahren noch nicht fertig. Ach ja, die Theorie ist falsch.

MfG
Peter

Auch wenn ich nicht so viel zur Diskussion über Register usw. beitragen kann, so kann ich doch zumindest Peter Lustig mit diesem Stück Code:

zeigen, daß es möglich ist, daß Variablen plötzlich "verschwindet".
- Optimierung bitte aktivieren
- Per Step durch die eizelnen Codezeilen gehen
- Die Variable i in der Watchlist im Auge behalten
Obwohl vorher und hinterher auf i zugegriffen wird, sagt der Debugger in der Zeile, in der die Höhe zugewiesen wird, daß auf i wegen Optimierung nicht zugegriffen werden kann.
Den Grund kann vielleicht Andy erklären

tommie-lie hat folgendes geschrieben:

Obwohl vorher und hinterher auf i zugegriffen wird, sagt der Debugger in der Zeile, in der die Höhe zugewiesen wird, daß auf i wegen Optimierung nicht zugegriffen werden kann.

Der Code in Assembler:

Der Compiler nimmt für i das EBX Register her und keine lokale Variable. Da Borland ja nicht schläft, haben die auch dem Debugger eine kleine Logik eingebaut und er kann erkennen, das i in EBX steht und zeigt es an.

Hier wird unser i (EBX) mit 100 multipliziert und in edx abgelegt. Danach wird EAX.SetWidth(edx) aufgerufen. Diese Funktion verändert mit unter auch das EBX Register, in dem unser i stand. Der Debugger kann nun durch das call feststellen, dass das Ursprungsregister seinen Wert verlohren haben könnte und sagt "Auf Variable 'i' kann wegen..."

Mein problem sitzt hier:



ich möchte ganz gern 'sender' oder 'a' auswerten, leider ist dies aber net möglich
edit: hintergrund wegen 'sender' ist, da ich einen weg suche, eine drag&drop koordinatenauswertung auf zeile/spalte/zelle zu bekommen. damit das gezogene element auch der zelle/zeile/spalte zugeordnet werden kann.

Daß du 'sender' nicht auslesen kannst liegt vermutlich wirklich daran, daß du es nicht benutzt. Zumindest habe ich ähnliche Phänomene auch schon beobachtet und musste dann irgendwelche Dummy-Operationen mit meinen Variablen ausführen, damit der Debugger sie nicht aus den Augen verliert.
'a' sollte, wenn ich Andy richtig verstanden habe, zumindest bis zur zweiten Zeile (test := ...) noch zugänglich sein, danach wird sie bei einem guten Compiler eh vollständig entfernt.

Könnte es nicht sein, dass der Compiler die ersten beiden Zeilen zu

umbaut?

wenn er erst die gesamte Prozedur parst und merkt, daß a nicht nochmal benötigt wird, wäre das sogar sehr wahrscheinlich.