Ich überprüfe ein C++ - MFC-Projekt. Zu Beginn des Jahres einige der Dateien gibt es diese Zeile:Warum #pragma optimieren ("", aus)
#pragma optimize("", off)
ich, dass diese Optimierung für alle folgenden Funktionen schaltet sich aus. Aber was wäre die Motivation dafür?
Ich habe gesehen, Produktionscode, der richtig ist, aber so kompliziert, dass es den Optimierer in die Herstellung falscher Ausgabe verwirrt. Dies könnte der Grund sein, Optimierungen abzuschalten.
Allerdings würde ich es viel wahrscheinlicher halten, dass der Code einfach fehlerhaft ist und Undefined Behavior hat. Der Optimierer stellt dies offen und führt zu falschem Laufzeitverhalten oder Abstürzen. Ohne Optimierungen passiert es, dass der Code "funktioniert". Und anstatt das zugrunde liegende Problem zu finden und zu entfernen, "reparierte" jemand es, indem es Optimierungen deaktivierte und es dabei beließ.
Natürlich ist das ungefähr so zerbrechlich und Workarounds können. Neue Hardware, neuer Betriebssystem-Patch, neuer Compiler-Patch, jeder dieser kann einen solchen "Fix" brechen.
Auch wenn das Pragma aus dem ersten Grund da ist, sollte es stark dokumentiert werden.
Danke. Keine Dokumentation zu diesen Zeilen. Ich schätze, ich werde versuchen, sie zu entfernen und nach Nebenwirkungen Ausschau zu halten. – Stokke
Ich habe dies ausschließlich verwendet, um bessere Debug-Informationen in einem bestimmten Satz von Code mit dem Rest der Anwendung ist mit der Optimierung auf kompiliert. Dies ist sehr nützlich, wenn das Ausführen eines vollständigen Debug-Builds aufgrund der Leistungsanforderungen Ihrer Anwendung nicht möglich ist.
Ich weiß, dass dies ein altes Thema ist, aber ich möchte hinzufügen, dass es einen anderen Grund gibt, diese Richtlinie zu verwenden - obwohl dies für die meisten Anwendungsentwickler nicht relevant ist.
Beim Schreiben von Gerätetreibern oder anderem Low-Level-Code erzeugt das Optimierungsprogramm manchmal Ausgaben, die nicht korrekt mit der Hardware interagieren.
Zum Beispiel Code, der ein memory-mapped-Register lesen muss (aber nicht den Wert lesen), um einen Interrupt zu löschen, könnte vom Compiler optimiert sein, Assembler-Code produzieren, der nicht funktioniert.
Dies könnte auch veranschaulichen, warum (wie Angew merkt) die Verwendung dieser Richtlinie klar dokumentiert werden sollte.
Ein weiterer alternativer Grund für diese in einer Code-Basis zu sein ... Es ist ein Unfall.
Dies ist ein sehr nützliches Tool, um den Optimierer während des Debuggens einer bestimmten Datei auszuschalten - wie oben erwähnt.
Wenn Änderungslisten vor der Übergabe nicht sorgfältig geprüft werden, ist es für diese Zeilen sehr einfach, in Codebasen einzudringen, weil sie "versehentlich" immer noch da waren, wenn andere Änderungen vorgenommen wurden.
Vielleicht mochte der Programmierer eine zuverlässige Stack-Trace, wenn das Programm bombardiert. Vielleicht hat er versucht, einen Codeoptimierer zu umgehen. Vielleicht wusste er nicht, was er tat, und wandte sich dem Frachtkult zu. –
Ein anderer Grund wäre, die resultierende Binärdatei zu verschleiern. Reverse Engineering schwieriger zu machen (natürlich, wenn der Quellcode offen ist, ist dies sinnlos). – freakish