Newsgroup: it.comp.lang.c++
Titolo: sostituire include path

Ciao a tutti!
Qualcuno sa come sostituire da codice un include path?
Io linko una libreria, diciamo versione 1.0.
Vorrei poter cambiare versione e passare alla 1.1 tramite una define.
Ho provato a fare così:
// myfile.h
#define MYDEF
#ifdef MYDEF
#include <mylib\1.0\myinclude\header.h>
#else
#include <mylib\1.1\myinclude\header.h>
#endif
e fino qui tutto bene... il problema è che dentro header.h ci sono
riferimenti del genere.
//header.h
#include<myinclude\config.h>
#include<myinclude\file.h>
ecc....
ovviamente avendo messo come path globale (per es. "c:\mypath") quello
contenente entrambe le versioni, il compilatore genera errore dentro
header.h perchè non trova gli altri include.
inoltre, header.h è lo stesso per tutte le versioni, quindi non posso
nemmeno inlcudere entrambi i path globali (es: c:\mypath\mylib\1.0\ e
c:\mypath\mylib\1.1\); in questo caso il compilatore prenderebbe il
primo header.h che gli capita, non rispettando la versione.
Qualche idea?
Diego

 Qualche idea?
Dire al compilatore quale diretcory usare per l'inclde.
Se usi un IDE o qualcosa di simile per editore i sorgenti avrai da 
qualche parte un gestore dei profili, con da qualche parte un buco 
relativo a questi profili dove inserire le directories aggiuntive da 
considerare per gli include.
-- 
Articolo 33 della Costituzione italiana: L'arte e la scienza sono 
libere e libero ne è l'insegnamento

Io seguo l'insegnamento di Rob Pike, e i miei header file non
contengono nessuna #include.

 contengono nessuna #include.
Questo e' forse possibile in C, ma in C++ e' una follia.
Ciao,
Nicola

 contengono nessuna #include.
Prego?
mi sembra impossibile!
anzi sbagliato: ritengo che un buon header debba #includere tutto (e 
solo) ciň che usa. Sbaglio? (non credo perchč spiando codice di varie 
librerie sono tutte fatte cosě)
Scrivendo codice "di libreria" mi sono abituato a scrivere semplici file 
.cpp di test che verificano se sia possibile #includere ogni mio .h *da 
solo* senza errori di compilazione
GM

Nico


Secondo me una considerazione del genere puo' avere senso per i
framework, ma andrebbe fatta una distinzione tra header file pubblici
e privati. Sull'inclusione di header file in header file pubblici di
un framework da distribuire in versione compilata, forse la
considerazione acquista una qualche motivazione. Secondo me vale
sempre la pena di "scegliere cosa includere" piuttosto che fuggire da
tutto in modo allergico.
--*PaN!*
 
-- 
I'm using an evaluation license of nemo since 206 days.
You should really try it!
http://www.malcom-mac.com/nemo

 senza errori di compilazione
Io invece, scrivendo codice "di libreria", preferisco non mettere 
nessun include dentro i miei header. Al limite, per chi usa la mia 
libreria, e almeno io la uso la mia libreria :-), c'è un header 
generale che li contiene tutti, nell'ordine corretto.


 tutto in modo allergico.
Il vincolo fondamentale e' che dato un qualsiasi header un sorgente
contenente esclusivamente l'inclusione di tale header deve compilare
senza errori ne, possibilmente, warning.
E' buona norma poi limitare le inclusioni al minimo insieme di header
necessari per soddisfare il vincolo fondamentale.
Ciao,
Nicola

 
Non sono d'accordo:
se non sono stato chiaro, vedi l'ultimo messaggio di Nicola che dice 
esattamente quello che volevo dire io:
se il "cliente" della mia libreria #include un mio header, deve poterlo 
fare senza problemi e senza dovre capire qual'è l'ordine "giusto" e deve 
poter includere solo quello.
Ad esempio nella mia stl <algorithm> #include <memory>.
Sarebbe scomodo se l'utente che includesse <algorithm> e gli saltasse 
fuori qualche strano errore perchè manca <memory>...
Tra parentesi, lo "sforzo" di inserire tutti e soli gli header necessari 
ti aiuta a visualizzare meglio tutte le dipendenze della tua libreria...
Poi che per comodità ci sia un header che gli include tutti sono d'accordo.
GM

 Poi che per comodità ci sia un header che gli include tutti sono d'accordo.
Gli altri "devono" usare l'include generico.
Io preferisco avere problemi di compilazione, che risolvo di volta in 
volta. Tanto sul mio codice ci lavoro solo io, e questi sono problemi 
che risolvo in 5 secondi quando creo un modulo nuovo.



Concordo che in C++ e' dura, specialmente se si ha una di quelle
cervellotiche gerarchie di classi sparse nell'universo... ;-)
Comunque si, in C++ e' meglio avere gli include che includono altri
include per evitare problemi.
Mi chiedo pero' quanto complicato possa diventare manutenere il
Makefile per minimizzare la ricompilazione con tutti questi headers
che cambiano indirettamente.
Ogni giorno trovo sempre un motivo in piu' per non usare il C++ nei
miei progetti.
Al limite ci vediamo alla ACCU ad Aprile e ne parliamo...

 problemi che risolvo in 5 secondi quando creo un modulo nuovo.
Dipende un po' dalla dimensione della libreria... su una libreria
piccina posso anche essere d'accordo, ma se si dovesse fare una roba
del genere per, diciamo, boost (anche solo un include unico per
ciascuna libreria) le compilazioni s'allungherebbero a dismisura.
 
-- 
I'm using an evaluation license of nemo since 208 days.


 su una libreria piccina posso anche essere d'accordo
La libreria in se è grossa, ma l'ho messa in piedi in 10 anni. Con 
boost o std ti prendi quel che ti serve. Nel mio caso, se uso la mia 
libreria, preferisco vedere tutto, e lasciare fare al linker il 
togliere ciò che non serve.
Prima avevo un approccio, poi l'ho cambiato, magari domani lo ricambio. 
Ma di differenze sostanziali non ne ho viste. Per esempio c'è chi mette 
gli header in una directory e le implementazioni in un'altra. Io metto 
tutto, .h e .cpp in una unica directory, anche se ho directory diverse 
per "argomento".
Ecco, con il visual studio 2005, e per come gestisce oggi i precompiled 
header avere più directory è scomodo. Ma ho visto che a non usarli non 
mi cambia nulla.


 ho directory diverse per "argomento".
La separazione degli header dai C++ viene fatta di solito per
semplificarsi la vita nella distribuzione binaria (.a, .lib, .so,
dll). Per la cronaca, io (ma ho notato anche altri) faccio
distinzione tra header pubblici e header privati, mettendo i primi
nella directory degli include (che verra' pubblicata), e i secondi
nella directory sorgente. Non e' consentito ad un include pubblico di
includere un include privato, ovviamente.
--*PaN!*


 includere un include privato, ovviamente.
Questo come lo ottieni? Poi è "utile"?


 che cambiano indirettamente.
Beh gestire a mano le dipendenze di un programma che usa header annidati 
  diventa impossibile, ma ci sono sistemi automatici. Ogni IDE ha il suo 
e ogni sistema di build (jam, automake...) ha il suo, alla fine 
funzionano tutti piuttosto bene, se uno si fa i makefile a mano invece 
tipicamente puo` usare l'opzione -M di GCC per generarsi un file di 
"depends" da includere alla fine del makefile.
Bye,
  Gabry

  Poi è "utile"?
Molto. Se hai deciso che alcuni header sono privati, devono restarlo.
Anche perche' non e' detto che un framework venga utilizzato dalle
stesse persone che lo sviluppano, e tanto meno che gli utenti debbano
averne i sorgenti (che, come dicevo, nel mio caso comprendono i
sorgenti classici e gli header privati).
--*PaN!*
 
-- 
I'm using an evaluation license of nemo since 214 days.


 scapito di un po' di efficienza,
Ho capito. E' una tecnica che non uso più. Per mia fortuna chi usa il 
mio codice lavora nella mia stessa azienda, oppure è un cliente. Per 
motivi diversi è un bene che veda sempre il codice. Nel primo caso, e 
pure nel secondo, mi permette di dire: non ho tempo, è una stupidata, 
modificati il codice da te. Ovviamente io non supporterò le tue 
modifiche.


  modifiche.
Eh, capisco. Ma non sempre ti puoi permettere di distribuire il
codice, e a volte e' necessario fornire un'interfaccia pulita per far
si che gli utenti del prodotto "libreria" capiscano al volo come
usarlo.
--
Marco


 usarlo.
Il livello di cialtronaggine programmatoria dei clienti con cui abbiamo 
a che fare è tale che ce lo possiamo permettere. Alcuni sono pure dei 
grandi "nomi". Ovviamente le cose aziendalmente *importanti* sono 
compilate in C/C++ e i clienti ci accedono via socket e stop.
Un giorno dovrei occuparmi della crittografia del traffico, che oggi 
viaggia in chiaro, ma chi ha tempo di fare le cose? Per fortuna le 
scatole nere non sono accessbili da internet, ma solo dalle intranet 
del clienti, altrimenti sarebbe un problema molto serio.
