È sbagliato posizionare "include direttiva" nella funzione principale?

5

Si dice sempre che include directive s deve essere posizionato all'inizio di uno script. Il motivo principale è rendere le funzioni disponibili in tutto lo script. Indipendentemente da questo fatto, è sbagliato posizionare un include directive all'interno della funzione principale dove è necessario?

Ad esempio,

#include <stdio.h>
int main() {
#include <mysql.h>
}

Invece di

#include <mysql.h>
#include <stdio.h>
int main() {
}

Non sono stato in grado di trovare risultati diversi in termini di prestazioni o dimensioni del file compilato, ma è difficile giudicare questo fatto sulla base di semplici script. Mi chiedo se ha qualche effetto o svantaggio, o qualsiasi motivo per evitare questo approccio non standard.

    
posta Googlebot 21.08.2013 - 05:00
fonte

5 risposte

13

Dipende dal codice inserito nel file di inclusione.

Hai provato a inserire #include per < stdio.h > all'interno principale ()? A seconda di come la libreria standard è implementata sul tuo sistema, potrebbe non essere nemmeno compilata. I file di intestazione possono contenere non solo dichiarazioni di funzioni, ma definizioni di funzioni. La C standard non supporta le funzioni annidate.

Se il file di intestazione contiene dichiarazioni di funzioni e variabili, inserendole all'interno del corpo di main () limita il loro ambito.

Se il file di intestazione contiene solo macro del preprocessore, potrebbe funzionare, ma infastidirai tutti gli altri programmatori C spostando l'inclusione in un luogo inaspettato. Gli standard di codifica sono particolarmente importanti in C perché C ha così poche garanzie per impedirti di rovinare.

    
risposta data 21.08.2013 - 06:17
fonte
11

I programmatori C, nel complesso, si aspettano che le direttive #include siano all'inizio del file. Perché rischiare di confonderle senza alcun beneficio significativo?

    
risposta data 21.08.2013 - 05:18
fonte
6

Considera le possibili cose che possono essere trovate in un file di intestazione.

  • Macro preprocessore. Questi saranno disponibili da #include fino alla fine del file .c che include l'intestazione. Le macro di preprocessore non sono interessate all'ambito del blocco C (parentesi graffe), quindi anche se l'intestazione si trova all'interno di una funzione, le macro saranno ancora disponibili dopo la fine del blocco.
  • Dichiarazioni di tipi, variabili e funzioni. Il loro ambito sarà il blocco in cui si trova la direttiva #include . Di solito va bene. Tuttavia, funziona solo una volta. Quasi tutti i file includono i controlli intestazione, in modo che se il file viene incluso più di una volta (cosa che spesso accade a causa di intestazioni che richiedono altre intestazioni) il suo contenuto viene elaborato solo una volta. Quindi se #include la stessa intestazione in più funzioni, le dichiarazioni saranno disponibili solo la prima volta.
  • Definizioni di funzioni (o variabili, ma ciò è estremamente raro nelle intestazioni). A volte le intestazioni contengono piccole funzioni static che il compilatore può incorporare. Ciò causerà il fallimento della compilazione se la direttiva #include è all'interno della funzione, poiché (salvo alcune estensioni del compilatore) non è possibile definire una funzione all'interno di un'altra funzione.

Quindi non è solo una questione di stile: #include all'interno di una funzione spesso semplice non funziona.

Puoi mettere una direttiva #include ovunque sull'ambito del file (ad esempio all'esterno di una funzione) senza gravi effetti tecnici. Le entità che definisce saranno disponibili solo sotto la riga #include . È soprattutto una questione di stile, ma è inusuale e inutile, quindi confonderà i manutentori. Può anche portare a errori confusi se si definisce una variabile o una funzione con lo stesso nome di qualcosa dichiarato in un'intestazione, poiché in tal caso qualsiasi discrepanza verrà riportata nell'intestazione (o in un'intestazione inclusa in un'intestazione inclusa ... inclusa in quell'intestazione ), probabilmente usando una sintassi specifica per l'implementazione, piuttosto che nel tuo codice.

Quindi sì, è cattivo. Raggruppa tutte le tue direttive #include nella parte superiore del file, con nient'altro che commenti e occasionalmente #pragma o #define se indicato dalla documentazione dell'implementazione.

    
risposta data 21.08.2013 - 12:23
fonte
4

È veramente molto molto cattivo!

Il motivo è che molti file di header C includono molte macro come: -

 #if !defined(MYSTUFF_INCLUDED)          /* File not yet included? */
   #define MYSTUFF_INCLUDED                /* Show file now included */
   int variable1;
   int variable2;
 #endif

le variabili macro hanno un ambito "file" mentre tutte le variabili definite all'interno avranno scope di funzione se includi "#INCLUDE" all'interno di una funzione.

Quindi

    #include <stdio.h>
    int main() {
        #include <mysql.h>
        call doSql();
     }
     int doSql () {
        #include <mysql.h>
        .....
     }

Non verrà compilato come la variabile macro MYSQL è già definita e la seconda INCLUDE non definirà nulla.

    
risposta data 21.08.2013 - 08:39
fonte
0

lunghe cose a breve ... evitalo il più possibile, fallo solo quando è assolutamente necessario (non riesco a pensare a un caso in cui lo sia ma chissà), in per avere un codice pulito e mantenibile.

    
risposta data 31.08.2013 - 03:47
fonte

Leggi altre domande sui tag