Newsgroup: it.comp.lang.c++
Titolo: stile inclusioni header

salve a tutti,
dovendo includere header, riferiti a codice personale e non a librerie
di terze parti, quale stile è meglio adottare fra i due seguenti e
perché:
1. #include "..\\inc\\mio_file.h"
2. #include <mio_file.h> //e specificare poi nell'ambiente di sviluppo
quale è la dir dove recuperare tale file
io preferirei il primo perché leggendo il codice capisco subito quale
è il file in questione ma ho visto autorevoli pareri contrari
(
http://www.eptacom.net/pubblicazioni/cpp_stile/recomm.html
 --
raccomandazione 18)
quale è la vostra opinione?
Saluti.

in realtà, nella raccomandazione 17 dice chiaramente di utilizzare <>
per gli header di libreria e "" per quelli propri
riguardo alla 18, poi, il discorso, imho, è "dipende"... se hai un
file che per un qualche motivo è all'interno di una directory, ad
esempio se hai una directory diversa a seconda del sistema operativo
su cui compili e queste directory si trovano all'interno della dir del
progetto, allora vai con il percorso!
#include "linux/miofile.h"
(e NON utilizzare il backslash, perché non è portabile... oltretutto
non devi assolutamente usare il DOPPIO backslash, perché non ha senso
in questo contesto)
se invece il file si trova in un'altra cartella perché hai una
cartella in cui metti dei file che riutilizzi per vari progetti,
allora è opportuno inserire tale directory nel path degli include...
eventualmente puoi fare come boost e crearti una cartella in cui metti
la cartella coi file da includere, così che puoi scrivere sempre
#include <boost/quellochetipare.h>
e riconoscere subito che si tratta di un include della libreria
boost... stessa cosa fa VCL di borland, stessa cosa fa OpenGL
-- 
]\/[ad]\/[age (
www.mindreamz.net
)
"Un Maestro insegue semplicemente la sua visione di Eccellenza in
qualunque cosa sta facendo e lascia agli altri decidere se sta 
lavorando o giocando. A lui sembra sempre di fare entrambe." - Anonimo

 quale è la dir dove recuperare tale file
In generale io adotto il medesimo schema, sia che si tratti di codice
"privato" sia che si tratti di header pubblici (di una mia libreria, ad
esempio).
Ogni gruppo di header che fa riferimento alla medesima libreria o
applicazione, o a una sotto-componente, riceve una propria directory con un
nome sufficientemente evocativo e possibilmente univoco. Gli header verrano
sempre #inclusi specificando il nome "nudo" della directory (non il percorso
completo) e il nome del file:
  #include "pippo_lib/config.h"
In questo modo, mi proteggo decentemente contro il rischio di omonimia nei
nomi degli header.
Inoltre chi legge il codice sa immediatamente se l'header #incluso
appartiene allo stesso progetto o a qualcosa di esterno.
Collocando i sorgenti in sottodirectory di una stessa directory, mi è
sufficiente aggiungere questa directory nel percorso di ricerca degli
header.
Per inciso, non uso mai '\' come separatore, ma sempre '/', che è
interpretato sia in ambiente Win32 che in ambiente *unix.
Max

la raccomandazione 29 non l'ho capita... vorrebbe dire che devo
scrivere
(((cout << "abcd") << intero) << stringa);
?!?!?!?
anche la 31 è sibillina, per me... perché non dovrei utilizzare un
parametro formale? se c'è vuol dire che serve, se non serve non ci
deve essere
la 38 l'ho vista fare spesso (ad esempio nel codice stl o std), ma me
ne sfugge il motivo
per la 43: perché allora è possibile non scrivere il private
all'inizio?
class miaclasse {
	int a, b;
public:
	int c, d;
};
per la 45 sono scettico, ho visto spesso fare l'esatto contrario
la 53 è anche incomprensibile, per me
per la 74 non vedo motivo... i metodi get e set, ad esempio in java,
hanno un senso particolare: consentire la modifica dei membri privati,
ma controllarne il valore prima (o evitare la lettura o la scrittura
pubblica)
per la 76: a meno che non siano funzioni che accedano a membri
pubblici e restituiscano il reference a tali membri


 pubblici e restituiscano il reference a tali membri
Beh... allora usa delle variabili globali, che è lo stesso :-)
-- 
Gerolamo
www.overweb.it