Newsgroup: it.comp.lang.c++
Titolo: [MT] Organizzare i progetti

Non e' troppo IT, pero' non trovo un NG sul Visual Studio dove chiedere...
Sto' cercando di capire quali sono i modi ed i mezzi forniti dal C in
generale e dal DevStudio in particolare per organizzare i propri progetti e
lavori.
Ad esempio:
Ho realizzato un "modulo" che serve a gestire la camera all'interno delle
DirectX. Questo "modulo" e' composto dai file camera.cpp e camera.h. Il file
.cpp chiaramente ha l'include del file .h, che contiene tutte le variabili
che devono essere visibili dall'esterno e la dichiarazione delle funzioni
contenute nel .cpp (dovrebbe essere normale, no?)
(nota: non uso le classi e mai lo faro')
I due file di cui sopra li ho inseriti in una apposita cartella in cui ho
intenzione di mettere tutti i "moduli" che sviluppero' per i miei
progetti...unica cosa, non li ho compilati in un .lib in quanto ci devo
comunque lavorare su in continuazione, cosi' preferisco che vengano
rebuildati ogni volta.
Ora, fin qui funziona tutto bene (direi, non ho fatto nulla :-) )
Sono le fasi successive che mi incasinano!
Intanto non riesco a dire ad altri progetti di usare i due file di cui
sopra, perlomeno non in maniera a me congeniale. La cosa che mi sembra(va)
piu' ovvia e semplice e' quella di dire al progetto di includere camera.h,
ma poi chiaramente camera.h non fa' automaticamente riferimento a camera.cpp
(include al contrario? :-D )
Ovviamente se oltre all'include del file .h dico al progetto di aggiungere
anche il file camera.cpp tutto funziona bene...pero' non e' esattamente come
volevo io.
(se tolgo il .h e lascio il .cpp mi da' un bel po' di unresolved external,
giustamente)
Altro problema: i doppi include.
In sostanza: camera.cpp fa' riferimento a variabili dichiarate in camera.h
(fin qui...)
Il progetto anch'esso deve far riferimento a delle variabili dichiarate in
camera.h (la variabile che rappresenta la camera, tanto per)
Risultato: un mucchio di errori di "redefinition", in quanto le variabili
vengono incluse due volte...
Ora, il Pragma Once non mi entusiasmava (dovunque leggo che serve solo a
risolvere errori di progetto fatti dal programmatore...), cosi' ho risolto
il problema dichiarando le variabili extern nel .h ed effettuando le
dichiarazioni vere e proprie nel .cpp
Ora, tutto funziona senza problemi. Pero' mi pare fin troppo complicato e
farruginoso...cioe', siamo d'accordo che il C(con o senza il ++) sia un
linguaggio complesso...pero' sono 6 anni che ci programmo (anche per lavoro)
ed i compilatori non mi sembra che si siano poi evoluti un granche' (almeno
il DevStudio)...
O sono io che sto' facendo della confusione?

 ed i compilatori non mi sembra che si siano poi evoluti un granche'
In verità tutto ciò non è affatto particolarmente complesso. Può sembrare
particolarmente complesso se devi capire come funziona per tentativi,
sbattendoci la testa, come hai fatto tu (e io avrei le stesse tue difficoltà
se dovessi capirlo senza un libro di riferimento), ma il meccanismo che sta
dietro i file header è spiegato benissimo in 5-10 pagine sul Lippman. Ci
sono cose molto più temibili...... cose che neppure i libri di Lippman e
Stroustrup riescono a spiegare in modo chiaro.

 Stroustrup riescono a spiegare in modo chiaro.
Sempre sia lodato e-Donkey :-)
Adesso mi leggo il libro in questione, va'...

 Adesso mi leggo il libro in questione, va'...
Scelta molto saggia.
La mia capacità di esposizione è paragonabile a quella di un bambino di 4
anni, fortunatamente per tutti Lippman spiega un pochino meglio.

 (nota: non uso le classi e mai lo faro')
Io la vedo cosi':
Esistono molte persone che sono completamente class-happy specialmente
quelle che derivano da Java. Alcuni vedono qualsiasi cosa come una classe, e
pensano che praticamente ogni classe debba derivare da qualche cosa (solo
per sentirsi bravi ed aver usato "inheritance" etc... Questo a mio avviso e'
sbagliato! A volte esagerare rende il codice paradossalmente piu' complicato
invece che piu' semplice, e lo rende anche piu' lento.
Detto questo la OO se usata con criterio non e' per nulla male!
Quello che si raccontava un volta, cioe' che passando da un linguaggio
procedurale ad uno OO si sarebbe diventati automaticamente piu' produttivi
e' evidentemente una favola... non e' cosi' semplice... bisogna saper
sfruttare bene la OO.
In un certo senso la OO e' stata deludente, ma per altri versi la OO e'
stata un enorme successo!
Io credo che chiunque esprima un parere come il tuo ha visto solo i lati
negativi della OO e spesso questo deriva dal fatto che non ha studiato
abbastanza per saperla sfruttare in modo positivo.
Il C++ e' un linguaggio che supporta la OO e nonostante, al contrario di
Java, permetta anche un paradigma non OO, e' persino piu' OO di Java per
altri versi.
Proprio perche' il C++ permetto un paradigma misto, ti permette di usare le
classi solo quando relamente ti sono utili (se vuoi). Quindi, in teoria,
anche una persona come te che non ama le classi, in C++ dovrebbe poterle
usare sporadicamente.
Tommy

 [zip]
Ovvero:
"Cerca sempre di conoscere bene tutti gli strumenti che hai a disposizione
ma usali solo quando servono".
Il mio modo di pensare.

 Il mio modo di pensare.
Appunto. Conosco la OOP e quello che puo' fare. Ho deciso di non usarla,
perche' non mi server. Amen :-)

 
Forse ti stai solo ingannando. Tu credi di non usare OOP ma in realta' lo 
stai facendo, con lo svantaggio di non poterne sfruttarne a pieno le 
potenzialita'.
Tanto per dirne una, il tuo modulo per la gestione della 
telecamera...scommetto che hai definito una cosa del tipo:
struct TELECAMERA
{
....
...
};
E poi una serie di funzioni (incluse nel .h del tipo)
Cam_MuoviAvanti (TELECAMERA *cam);
Cam_RuotaAttornoAsseX (TELECAMERA *cam,float radianti);
Beh se al posto di struct scrivi class e se invece che dichiarare le 
funzioni al di fuori delle parentesi graffe le metti nelle parentesi 
graffe, hai una classe.
Uno dei vantaggi e' che non devi passare tutte le volte il parametro 
TELECAMERA *cam per esempio.
Di svantaggi non ne vedo....
Di fatto stai usando una rozza versione della programmazione ad oggetti e 
forse a questo punto sarebbe il caso di usarla per davvero no?

 graffe, hai una classe.
Anche senza scrivere class... le struct sono di fatto classi con public di
default invece che private.
Tommy

 
...e visto che di fatto le usi allora non sarebbe meglio usare 
'ufficialmente' e sfruttare il supporto del compiolatore ?