Das ist natürlich schon ein Problem.
Auf der einen Seite kann Debuggen von optimiertem Code frustrierend sein
- Debuggen von optimiertem Code kann so zu Stress ausarten. Auf der
anderen Seite deckt der Optmizer so manchen Programmfehler auf, der ohne
Optimizer nicht existiert, bzw. sich nicht auswirkt.
Man kann zb so vorgehen: Entwickeln ohne Optimizer. Im Debugger kann man
sich Abläufe ansehen, Variablen verfolgen. Dann wird der Optimizer
zugeschaltet. Verhält sich dann das Programm anders, so hat man irgendwo
gegen eine C-Regel verstossen, die vom Optimizer gnadenlos ausgenutzt
wird. Man kann jetzt versuchen, den optimierten Code im Debugger nur im
Hinblick darauf zu untersuchen. Dazu gehören Variablen ansehen, sofern
sie nicht entfernt wurden, aber der Optimizer ist an dieser Stelle oft
eher nutzlos geworden. Hier muss man dann auf andere Debugmöglichkeiten
wie strategische Ausgaben, Leds die aufleuchten, etc. zurückgreifen und
den Rest per Umkehrschluss und erhöhtem Einsatz der grauen Zellen
erledigen.
Das geht aber nur dann, wenn das Verfahren prinzipiell schon ausgetestet
und für gut befunden wurde. Dazu benötigt es aber den Optimizer meistens
nicht.
Es empfiehlt sich auch während der Entwicklungsarbeit immer wieder mal
zur Optimizer Variante zu schalten und den Code dort zu testen und
gefundenen Ungereimtheiten sofort nachzugehen. Je länger man das
hinauszögert, umso mehr Code hat man dann, der ein potentieller
Übeltäter sein kann.
