Newsgroup: it.comp.lang.c
Titolo: E' male includere più volte lo stesso header?

Ciao a tutti.
Molte volte mi capita di scrivere inconsapevolmente, o di vedere 
scritti, programmi che includono più volte lo stesso header file, oppure 
includono header che in realtà non servono. Il caso più frequente si 
verifica quando vengono inclusi degli header che in realtà sono già 
inclusi da header che avevamo incluso in precedenza. 
Chiedo scusa per l'orribile giro di parole, ma non sapevo proprio come 
cazzarola esprimere questo concetto! :-)
La domanda: volevo sapere se simili circostanze aumentano inutilmente le 
dimensioni degli eseguibili, e, più in generale, se ci sono delle 
controindicazioni.
Grazie e un saluto.
Bizio.



Se gli header sono scritti correttamente includere più volte lo stesso 
file non causa alcun problema se non un maggior uso di risorse da 
parte del compilatore ed in genere un maggior tempo di compilazione. 
Cosa che con i moderni processori non è un grave problema come in passato.
È normale inserire negli headers una macro per fare in modo che il 
corpo dell'header se incluso più volte venga processato solo la prima. 
  Senza di questo, includere più volte un header può generare errori. 
  Per esempio:
#if ! defined I_STDIO_H
#define I_STDIO_H
/* corpo dell'header */
. . . . . .
#endif
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   Registered Linux user #337974  < 
http://giovanni.homelinux.net/
 >

 controindicazioni.
No, a tutte e due le domande. E' buona regola usare degli "header guard"
per evitare dichiarazioni/definizioni doppie, quindi, ogni header file è
di solito nella forma:
/* pippo.h */
#ifndef PIPPO_H
#define PIPPO_H
....
#endif
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

In generale e' uso coumne usare gli header guards (come menzionato
dall'utente qui sopra).
C'e' da dire pero' che ci sono due fazioni. Quella che usa le guards e
quella che non le usa.
Io appartengo a quella che non le usa.
GLi stessi autori ci C e Unix, e successivamente di Plan9, infatti
sconsigliano di usare header guard e di dichiarare esplicitamente che
header sono necessari come documentazione per l'utente.
In plan9 per esempio nessuno degli header di sistema usa le header
guards, e gli autori del sistema ne sconsigliano l'utilizzo.
In generale quindi, per questa fazione, se tu hai un header1.h che
dipende da header2.h, devi dichiarare (magari in un commento)
all'utente di header1.h che deve essere lui, nel suo modulo module.c,
ad includere i moduli nell'ordine giusto.
#include "header2.h"
#include "header1.h"
Non sto dicendo che usare header guards sia sbagliato.
Sto solo dicendo che ci sono due fazioni (un po' come vi ed emacs) e
che quindi e' una tua scelta quale politica scegliere.
In generale se  hai a che fare con un gruppo di programmatori dove
molti sono abituati alle header guards e' meglio se le usi.
Se invece puoi imporre la tua opinione sul gruppo e non ti piacciono
le header guards, basta che lo stabilisci all'inizio e chi fa errori
paga.
Per portare acqua al proprio mulino in questo secondo caso basta
menzionare la guida allo stile di programmazione di Rob Pike e il
paragrafo su Include Files: 
http://www.di-mgt.com.au/src/pikestyle.html

 wrote in message
news:MPG.21e6ab52...@news.fastwebnet.it...
