Sono necessarie protezioni ridondanti?

Le “protezioni aggiuntive ridondanti” sono necessarie in Codegear RAD Studio 2009? Il compilatore è abbastanza intelligente da occuparsene da solo?

Ad esempio, potrei avere il seguente comando “include guard” in foo.h:

#ifndef fooH #define fooH // ... declaration here #endif 

e il seguente ‘ridondante include guardia’ in use_foo.h:

 #ifndef fooH #include "foo.h" #endif 

Inoltre, se il compilatore non è abbastanza intelligente, sono necesarry ‘ridondanti di protezioni incluse’ se vengono inclusi in un file sorgente. ad es. use_foo.cpp . ?

La parte del codice che hai contrassegnato come “ridondante include guardia” non è necessaria ma è una ansible ottimizzazione.

Nel caso di C ++ Builder, esiste una logica per rilevare le protezioni intestazione, quindi non dovrebbe essere necessario.

Nel caso generale, il passaggio di preelaborazione è in genere piuttosto veloce, quindi è improbabile che questa ottimizzazione ti comprerebbe comunque.

Queste guardie ridondanti sono pensate per emulare la funzionalità della direttiva proposta #pragma once : se un file di intestazione è già stato incluso, allora il preprocessore non tenterà nemmeno di localizzarlo, aprirlo e analizzarlo (come invece dovrebbe “ordinario” include la tecnica di guardia). In molti casi ciò rende la gestione dei file include molto più efficiente (velocizza la compilazione).

Questo approccio è ovviamente di alta manutenzione: è necessario assicurarsi che l’ortografia del simbolo di guardia sia esattamente la stessa all’interno del file di intestazione e anche all’esterno.

La “ridondante guardia include”, come la chiami, accelera la compilazione.

Senza la guardia ridondante, il compilatore eseguirà l’iterazione dell’intero file foo.h, cercando un codice che potrebbe trovarsi al di fuori del blocco #ifndef . Se è un file lungo, e questo è fatto in molti posti, il compilatore potrebbe perdere un sacco di tempo. Ma con la guardia ridondante, può saltare l’intera frase #include e nemmeno riaprire quel file.

Ovviamente, dovresti sperimentare e vedere la quantità di tempo sprecata dal compilatore che itera su foo.h e non compila effettivamente nulla; e forse i compilatori moderni in realtà cercano questo modello e sanno automaticamente di non preoccuparsi di aprire il file, non lo so.

(Inizia la modifica con 280Z28)

La seguente struttura di intestazione è riconosciuta da almeno GCC e MSVC. L’utilizzo di questo schema annulla praticamente tutti i vantaggi che potresti ottenere con le guardie nei file inclusi. Si noti che i commenti vengono ignorati quando il compilatore esamina la struttura.

 // GCC will recognize this structure and not reopen the file #ifndef SOMEHEADER_H_INCLUDED #define SOMEHEADER_H_INCLUDED // Visual C++ uses #pragma once to mark headers that shouldn't be reopened #if defined(_MSC_VER) && (_MSC_VER >= 1020) # pragma once #endif // header text goes here. #endif 

(Fine modifica)