#Pragma è una volta sicuro includere la guardia?

Ho letto che c'è qualche ottimizzazione del compilatore durante l'utilizzo #pragma onceche può portare a una compilazione più veloce. Riconosco che non è standard e quindi potrebbe rappresentare un problema di compatibilità multipiattaforma.

È qualcosa che è supportato dalla maggior parte dei compilatori moderni su piattaforme non Windows (gcc)?

Voglio evitare problemi di compilazione della piattaforma, ma voglio anche evitare il lavoro extra delle protezioni di fallback:

#pragma once
#ifndef HEADER_H
#define HEADER_H

...

#endif // HEADER_H

Dovrei essere preoccupato? Dovrei spendere ulteriore energia mentale su questo?

L'utilizzo #pragma oncedovrebbe funzionare su qualsiasi compilatore moderno, ma non vedo alcun motivo per non utilizzare una #ifndefprotezione include standard . Funziona benissimo. L'unica avvertenza è che GCC non supportava #pragma onceprima della versione 3.4 .

Ho anche scoperto che, almeno su GCC, riconosce lo standard #ifndefinclude guard e lo ottimizza , quindi non dovrebbe essere molto più lento di #pragma once.

#pragma once ha uno svantaggio (oltre ad essere non standard) e cioè se hai lo stesso file in posizioni diverse (lo abbiamo perché il nostro sistema di build copia i file) quindi il compilatore penserà che si tratti di file diversi.

Vorrei #pragma once(o qualcosa del genere) fosse stato nello standard. Includere le guardie non è un grosso problema (ma sembrano essere un po 'difficili da spiegare alle persone che imparano la lingua), ma sembra un piccolo fastidio che avrebbe potuto essere evitato.

In effetti, dal 99,98% delle volte, il #pragma oncecomportamento è il comportamento desiderato, sarebbe stato bello se la prevenzione dell'inclusione multipla di un'intestazione fosse gestita automaticamente dal compilatore, con un #pragmao qualcosa per consentire il doppio inclusione.

Ma abbiamo quello che abbiamo (tranne che potresti non averlo #pragma once).

Non conosco alcun vantaggio in termini di prestazioni, ma sicuramente funziona. Lo uso in tutti i miei progetti C ++ (ammesso che sto usando il compilatore MS). Trovo che sia più efficace dell'uso

#ifndef HEADERNAME_H
#define HEADERNAME_H
...
#endif

Fa lo stesso lavoro e non popola il preprocessore con macro aggiuntive.

GCC supporta #pragma onceufficialmente dalla versione 3.4 .

GCC supporta #pragma oncedal 3.4, vedi http://en.wikipedia.org/wiki/Pragma_once per ulteriore supporto del compilatore.

Il grande vantaggio che vedo sull'uso #pragma onceinvece di includere guardie è di evitare errori di copia / incolla.

Ammettiamolo: la maggior parte di noi difficilmente avvia un nuovo file di intestazione da zero, ma piuttosto ne copia uno esistente e lo modifica alle nostre esigenze. È molto più semplice creare un modello di lavoro usando #pragma onceinvece di includere protezioni. Meno devo modificare il modello, meno è probabile che si verifichino errori. Avere la stessa funzione include guard in file diversi porta a strani errori del compilatore e ci vuole del tempo per capire cosa è andato storto.

TL; DR: #pragma onceè più facile da usare.

Lo uso e ne sono contento, poiché devo digitare molto meno per creare una nuova intestazione. Ha funzionato bene per me su tre piattaforme: Windows, Mac e Linux.

Non ho alcuna informazione sulle prestazioni ma credo che la differenza tra #pragma e include guard non sarà nulla in confronto alla lentezza dell'analisi della grammatica C ++. Questo è il vero problema. Prova a compilare lo stesso numero di file e linee con un compilatore C # per esempio, per vedere la differenza.

Alla fine, usando la guardia o il pragma, non importa affatto.

L'uso di " #pragma once" potrebbe non avere alcun effetto (non è supportato ovunque, anche se è sempre più ampiamente supportato), quindi è necessario utilizzare comunque il codice di compilazione condizionale, nel qual caso, perché preoccuparsi di " #pragma once"? Il compilatore probabilmente lo ottimizza comunque. Tuttavia, dipende dalle piattaforme di destinazione. Se tutti i tuoi bersagli lo supportano, vai avanti e usalo, ma dovrebbe essere una decisione consapevole perché si scatenerà l'inferno se usi solo il pragma e quindi esegui il port su un compilatore che non lo supporta.

Il vantaggio in termini di prestazioni è di non dover riaprire il file dopo aver letto #pragma. Con guards, il compilatore deve aprire il file (che può essere costoso in tempo) per ottenere le informazioni che non dovrebbe includere di nuovo il suo contenuto.

Questa è teoria solo perché alcuni compilatori non apriranno automaticamente i file per i quali non è stato letto alcun codice di lettura, per ciascuna unità di compilazione.

Comunque, non è il caso di tutti i compilatori, quindi idealmente #pragma deve essere evitato una volta che il codice multipiattaforma non è affatto standard / non ha definizione ed effetto standardizzati. Tuttavia, praticamente, è davvero meglio delle guardie.

Alla fine, il miglior suggerimento che puoi ottenere per essere sicuro di avere la migliore velocità dal tuo compilatore senza dover controllare il comportamento di ciascun compilatore in questo caso, è usare sia pragma una volta che guardie.

#ifndef NR_TEST_H
#define NR_TEST_H
#pragma once

#include "Thing.h"

namespace MyApp
{
 // ...
}

#endif

In questo modo ottieni il meglio da entrambi (multipiattaforma e aiuto nella velocità di compilazione).

Poiché è più lungo da digitare, uso personalmente uno strumento per aiutare a generare tutto ciò in modo molto malvagio (Visual Assist X).

Non sempre.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52566 ha un bell'esempio di due file pensati per essere inclusi entrambi, ma erroneamente ritenuti identici a causa di timestamp e contenuto identici (non identico nome del file) .

Usando gcc 3.4 e 4.1 su alberi molto grandi (a volte usando distcc ), devo ancora vedere una maggiore velocità quando uso #pragma una volta al posto di, o in combinazione con le protezioni standard include.

Davvero non vedo quanto valga la pena confondere le versioni precedenti di gcc, o anche altri compilatori poiché non ci sono risparmi reali. Non ho provato tutti i vari de-linters, ma sono disposto a scommettere che confonderà molti di loro.

Anch'io vorrei che fosse stato adottato all'inizio, ma posso vedere l'argomento "Perché ne abbiamo bisogno quando ifndef funziona perfettamente?". Dati i molti angoli oscuri e le complessità di C, le guardie sono una delle cose più semplici e autoesplicative. Se hai anche una piccola conoscenza di come funziona il preprocessore, dovrebbero essere autoesplicativi.

Se si osserva una notevole accelerazione, tuttavia, si prega di aggiornare la domanda.

Oggi la vecchia scuola include che le guardie sono veloci quanto una #pragma una volta. Anche se il compilatore non li tratta in modo speciale, si fermerà comunque quando vedrà #ifndef WHATEVER e WHATEVER definiti. L'apertura di un file è poco costoso oggi. Anche se ci fosse un miglioramento, sarebbe nell'ordine dei millisecondi.

Semplicemente non uso #pragma una volta, poiché non ha alcun vantaggio. Per evitare di scontrarmi con altre guardie di inclusione uso qualcosa del tipo: CI_APP_MODULE_FILE_H -> CI = Iniziali dell'azienda; APP = Nome dell'applicazione; il resto si spiega da sé.

La differenza principale è che il compilatore ha dovuto aprire il file header per leggere la protezione include. In confronto, una volta pragma fa sì che il compilatore tenga traccia del file e non esegua alcun IO di file quando incontra un altro include per lo stesso file. Anche se può sembrare trascurabile, può facilmente espandersi con grandi progetti, specialmente quelli senza una buona intestazione includono discipline.

Detto questo, in questi giorni i compilatori (incluso GCC) sono abbastanza intelligenti da trattare una volta le guardie come il pragma. cioè non aprono il file ed evitano la penalità IO del file.

Nei compilatori che non supportano il pragma ho visto implementazioni manuali un po 'ingombranti ..

#ifdef FOO_H
#include "foo.h"
#endif

Personalmente mi piace l'approccio #pragma una volta che evita il fastidio di nominare collisioni e potenziali errori di battitura. È anche un codice più elegante al confronto. Detto questo, per il codice portatile, non dovrebbe far male avere entrambi a meno che il compilatore non si lamenta.

Se utilizziamo msvc o Qt (fino a Qt 4.5), poiché GCC (fino a 3.4), entrambi supportano msvc #pragma once, non vedo alcun motivo per non utilizzarlo #pragma once.

Il nome del file sorgente di solito ha lo stesso nome di classe uguale e sappiamo, a volte abbiamo bisogno di refactor , per rinominare il nome della classe, quindi abbiamo dovuto cambiare #include XXXXanche il, quindi penso che il mantenimento manuale #include xxxxxnon sia un lavoro intelligente. anche con l'estensione Visual Assist X, mantenere "xxxx" non è un lavoro necessario.

Nota aggiuntiva per le persone che pensano che un'inclusione automatica di una sola volta di file di intestazione sia sempre desiderata: costruisco generatori di codice usando l'inclusione doppia o multipla di file di intestazione da decenni. Soprattutto per la generazione di stub di librerie di protocollo trovo molto comodo avere un generatore di codice estremamente portatile e potente senza strumenti e linguaggi aggiuntivi. Non sono l'unico sviluppatore a utilizzare questo schema come mostrano i blog X-Macros . Ciò non sarebbe possibile senza la protezione automatica mancante.