sto rivedendo un progetto di C++ MFC. All'inizio di alcuni dei file c'è questa linea:Perché #pragma optimize ("", off)
#pragma optimize("", off)
Ottengo che questo si trasforma ottimizzazione off per tutte le seguenti funzioni. Ma quale sarebbe in genere la motivazione per farlo?
Ho visto codice di produzione corretto ma così complicato da confondere l'ottimizzatore in una produzione errata. Questo potrebbe essere il motivo per disattivare le ottimizzazioni.
Tuttavia, ritengo molto più probabile che il codice sia semplicemente buggato, con comportamento non definito. L'ottimizzatore lo espone e causa comportamenti o arresti anomali del runtime non corretti. Senza ottimizzazioni, il codice capita di "lavorare". E invece di trovare e rimuovere il problema sottostante, qualcuno lo ha "risolto" disabilitando le ottimizzazioni e lasciandolo lì.
Ovviamente, questo è il più delicato e si possono ottenere soluzioni alternative. Nuovo hardware, nuova patch del sistema operativo, nuova patch del compilatore, ognuno di questi può rompere una "correzione" del genere.
Anche se il pragma è lì per la prima ragione, dovrebbe essere molto documentato.
Grazie. Nessuna documentazione che circonda quelle linee. Credo che farò un tentativo di rimuoverli e tenere d'occhio gli effetti collaterali. – Stokke
L'ho usato esclusivamente per ottenere informazioni di debug migliori in un particolare set di codice con il resto dell'applicazione compilato con l'ottimizzazione attivata. Questo è molto utile quando è impossibile eseguire una compilazione di debug completa a causa dei requisiti prestazionali dell'applicazione.
So che questo è un argomento vecchio, ma vorrei aggiungere che c'è un altro motivo per usare questa direttiva - sebbene non sia rilevante per la maggior parte degli sviluppatori di applicazioni.
Durante la scrittura di driver di periferica o di altro codice di basso livello, l'ottimizzatore talvolta produce output che non interagiscono correttamente con l'hardware.
Ad esempio il codice che deve leggere un registro mappato in memoria (ma non utilizzare il valore letto) per cancellare un interrupt potrebbe essere ottimizzato da dal compilatore, producendo codice assembly che non funziona.
Questo potrebbe anche illustrare perché (come osserva Angew) l'uso di questa direttiva dovrebbe essere chiaramente documentato.
Un'altra ragione alternativa per questi ad essere in una base di codice ... Il suo un incidente.
Si tratta di uno strumento molto utile per spegnere l'ottimizzatore su un file specifico, mentre il debug - come Ray di cui sopra.
Se gli elenchi di modifiche non vengono esaminati attentamente prima di eseguire il commit, è molto facile che queste linee si inseriscano nelle codebase, semplicemente perché erano "accidentalmente" ancora presenti quando venivano apportate altre modifiche.
Forse il programmatore è piaciuto una traccia dello stack affidabile quando le bombe del programma. Forse ha cercato di aggirare un bug di ottimizzazione del codice. Forse non sapeva cosa stava facendo e ha applicato il culto del carico. –
Un altro motivo potrebbe essere quello di offuscare il risultato binario. Per rendere il reverse engineering più difficile (ovviamente se il codice sorgente è aperto questo è inutile). – freakish