Pourquoi #pragma optimiser ("", désactivé)
J'examine un projet C++ MFC. Au début de certains fichiers, il y a cette ligne:
#pragma optimize("", off)
J'obtiens que cela désactive l'optimisation pour toutes les fonctions suivantes. Mais quelle serait généralement la motivation pour le faire?
J'ai vu du code de production qui est correct mais si compliqué qu'il confond l'optimiseur en produisant une sortie incorrecte. Cela pourrait être la raison de désactiver les optimisations.
Cependant, je considérerais qu'il est beaucoup plus probable que le code soit simplement bogué, ayant un comportement indéfini. L'optimiseur expose cela et conduit à un comportement d'exécution incorrect ou à des plantages. Sans optimisations, le code arrive à "fonctionner". Et plutôt que de trouver et de supprimer le problème sous-jacent, quelqu'un l'a "corrigé" en désactivant les optimisations et en le laissant ainsi.
Bien sûr, c'est à peu près aussi fragile et les solutions de contournement peuvent être. Nouveau matériel, nouveau patch du système d'exploitation, nouveau patch du compilateur, tout cela peut casser un tel "correctif".
Même si le pragma est là pour la première raison, il devrait être largement documenté.
J'ai utilisé cela exclusivement pour obtenir de meilleures informations de débogage dans un ensemble particulier de code avec le reste de l'application compilé avec l'optimisation activée. Ceci est très utile lorsque l'exécution avec une version de débogage complète est impossible en raison des exigences de performances de votre application.
Une autre raison alternative pour qu'ils soient dans une base de code ... C'est un accident.
Il s'agit d'un outil très pratique pour désactiver l'optimiseur sur un fichier spécifique pendant le débogage - comme Ray l'a mentionné ci-dessus.
Si les listes de modifications ne sont pas examinées attentivement avant de valider, il est très facile pour ces lignes de se frayer un chemin dans les bases de code, simplement parce qu'elles étaient "accidentellement" toujours là lorsque d'autres modifications ont été validées.
Je sais que c'est un vieux sujet, mais j'ajouterais qu'il y a une autre raison d'utiliser cette directive - bien qu'elle ne soit pas pertinente pour la plupart des développeurs d'applications.
Lors de l'écriture de pilotes de périphérique ou d'un autre code de bas niveau, l'optimiseur produit parfois une sortie qui n'interagit pas correctement avec le matériel.
Par exemple, le code qui doit lire un registre mappé en mémoire (mais pas utiliser la valeur lue) pour effacer une interruption peut être optimisé par le compilateur, produisant un code d'assembly qui ne fonctionne pas.
Cela pourrait également illustrer pourquoi (comme le note Angew) l'utilisation de cette directive devrait être clairement documentée.