Newsgroup: it.comp.lang.c++
Titolo: C++ e OpenGL

Sto studiando le OpenGL per un progetto che ho in mente.
Ho creato un primo programma in VC9, chiaramente in C++ e
al momento di linkarlo mi ritrovo 15 errori del linker, uno per ogni 
funzione OpenGL. Sono tutti di questo tipo:
unresolved external symbol __imp__glClear@4 referenced in function 
"public: void __thiscall MyAppView::OnPaint(void)" 
(?OnPaint@MyAppView@@QAEXXZ)
al che mi sono chiesto "ma non � che il VC decora i nomi delle funzioni 
OpenGL come fossero funzioni C++ e poi il linker non le trova???"
Nel file GL.H c'� un #ifdef __cplusplus che rende tutte le funzioni 
glQualcosa() definite extern C... e quindi perch� il VC9 fa cos�?

 glQualcosa() definite extern C... e quindi perché il VC9 fa così?
L'ipotesi piu' probabile e' che il linker non trovi le librerie.
ciao
Giacomo


metti:
opengl32.lib glu32.lib
nelle dipendenze aggiuntive del compilatore.

 nelle dipendenze aggiuntive del compilatore.
e infatti... :-(
La dir delle lib era gi� nel path del linker, pensavo che la prendesse 
in automatico. Invece no c'era da farlo a mano :-(

 
da cui si evince che gli ide fanno male... programmando un p� col vi e
la console saresti abituato a scrivere roba del tipo:
gcc
-I/usr/include/<<DIRECTORY_INCLUDE_PER_LIBRERIA>>
-L/usr/lib -l<<LIBRERIA_OMETTENDO_PREFISSO_LIB>>
.....
<<MIEI_SORGENTI>>
-o <<MIO_ESEGUIBILE>>
in pratica devi sempre specificare directory degli include, delle
librerie e quali librerie effettivamente linkare... alla fine sotto
quella directory potrebbero pure starcene mille e il compilatore che
dovrebbe fare linkarli tutti?
per dire...
ciauz!


Scusate se mi attacco, è orrendamente OT, potete
sfancularmi: con MinGW devo dire TUTTO nel makefile,
ma almeno mi piacerebbe risparmiarmi quelle righe di
variabile che contengono i path di alcune librerie
mie e altri "include". Ogni volta che cambio lettera
di unità o reinstallo il S.O. con qualche variante
devo rimettere mano a tutti i makefiles.
Esiste una specie di file di configurazione per
MinGW sotto XP in cui posso specificare tutti i
paths degli include e delle librerie? Non riesco a
trovarlo :(
-- 
"Non portare mai la tua donna alla
baia dei Porci. Lei capirà"

 
a parte scusa ma quante volte cambi lettera di unitï¿œ o rinstalli il tutto?
comunque potresti usare una unitï¿œ "virtuale" con subst ad esempio:
subst z: c:\programmi\mingw
la direttory programmi_mingw diventa l'unitï¿œ Z
fai tutti i makefile riferendoti quindi a Z...
se vuoi cambiare rimatti z a qualche altra dir:
substs z: /d (elimina)
e poi riassegni
probabilmente ï¿œ un qualcosa molto old-style visto che lo facevo col gcc
2.9 e windows 98 ma dovrebbe sempre funzionare...

 librerie e quali librerie effettivamente linkare...
...
una volta qualcuno mi ha insegnato che tra l'uomo e la macchina deve 
instaurarsi un "patto" nel quale l'uomo usa il cervello per insegnare 
*una volta per tutte* alla macchina cosa deve fare...
magari la prima volta ci mette un po di pi�... ma in futuro risparmia 
tempo, ed � pi� sicuro della correttezza del risultato.
L'IDE serve a questo.
Se non sai che devi specificare le librerie, non lo sai n� se usi l'ide 
n� se usi il vi, n� se programmi con le schede perforate...
Casomai il problema � distinguere tra "conoscere i concetti", e "saper 
riprodurre una procedura". Conosco gente che usa il vi come una scimmia, 
senza sapere cosa sta scrivendo ma seguendo semplicemente le istruzioni 
senza capire cosa ci sta sotto. Idem per gli IDE (fa quasi rima :) ).
Per inciso (magari aiuta l'OP), nei compilatori MS (ma credo esistano 
robe analoghe negli altri) con #pragma comment si possono specificare 
opzioni e comandi per il linker direttamente nei sorgenti 
http://support.microsoft.com/kb/153901/en-us
...alcuni produttori di librerie lo fanno direttamente negli header 
creando l'illusione che tutto sia automatico.
Vedi ad esempio
http://www.boost.org/doc/libs/1_42_0/boost/config/auto_link.hpp

 ...
ma io scherzavo eh...

 dovrebbe fare linkarli tutti?
Tipica risposta da programmatore duro e puro :-)
Beh per esempio, potrebbe crearsi una tantum un DB di tutte le funzioni 
in tutte le lib installate nel sistema, aggiornato ogni volta che uno 
installa una lib nuova. Cos� non avresti proprio bisogno di dire niente 
al linker su dove andare a pescare le lib, lo saprebbe gi� da solo... 
semmai ti chiederebbe interattivamente in caso di doppioni, tipo "la 
funzione StaFunz(argomentivari) � contenuta sia nella LibPincoPallo che 
nella LibCippaLippa: quale prendo?"
Ancora, visto che in un IDE la compilazione avviene con il programmatore 
l� davanti non sarebbe una cattiva idea prevedere una modalit� di 
"compilazione interattiva" in cui il compilatore o il linker chiede lumi 
al programmatore quando incontra una situazione errata o poco chiara. Se 
il linker mi avesse detto "queste funzioni non sono comprese in nessuna 
libreria che conosco, dimmi tu dove le devo cercare" io gliel'avrei 
detto subito e senza problemi. Invece ci ho messo mezza giornata a 
capire perch� non compilava :-(
Anch'io ho tribolato con i Makefile, tanto per precisare, e sono sempre 
stato del parere che siano troppo complicati per quello che fanno. 
Finch� erano portabili da una piattaforma all'altra valevano la pena, ma 
ormai non � pi� vero neppure quello: adesso per compilare un sorgente 
devi avere il Make di chi ha scritto il programma oppure moddarti il 
makefile a mano :-(
E infatti sono uscite alternative a Make, come Bake... che per� � pur 
sempre un'altra ennesima versione di Make :-(((
Insomma io mi chiedo perch� mai i programmatori debbano sempre e per 
forza usare strumenti che era logico usare quarant'anni fa, ma solo 
perch� all'epoca non si poteva fare niente di meglio di quello. Poi ci 
si lamenta che uno passa ai linguaggi dinamici... ettecredo. Abbiamo 
davanti macchine stellari e stiamo sempre l� a battere a macchina i 
makefile a mano. Ci deve essere un sistema migliore.


sante parole... non so davvero dove si andrà a
finire. Non riesco a capire se peserà di più il
fattore che non se ne può più di caratteristiche e
problematiche dipendenti dalla piattaforma o
l'opposto, quello di convenire su uno standard comune.
Io stesso non so da che parte "investire". Eclipse o
QT? Capisco programmare un videogame come Warcraft,
ma per applicazioni normali non sarebbe impossibile
che tutti gli interessati convenissero su un
ambiente di sviluppo totalmente indipendente dalla
piattaforma o quasi.
E non parliamo di "make", avessi trovato un Makefile
non banale in vita mia che non andasse modificato
persino per la propria macchina, non parliamo del
sistema operativo.
-- 
Diffida di chi ti da' consigli
e poi ti insulta, imbecille! :)

Archaeopteryx ha scritto:
OT-totale
deliziosa firma.
Rilancio con :
"Rilassati ... PRESTOOO !"

 capire perch� non compilava :-(
Guarda che � successo esattamente quello che chiedi.
Rileggi l'errore:
unresolved external symbol __imp__glClear@4 referenced in function 
"public: void __thiscall MyAppView::OnPaint(void)" 
(?OnPaint@MyAppView@@QAEXXZ)
Significa esattamente che il simbolo __imp__glClear@4 � sconosciuto al 
linker. Siccome quel simbolo non l'hai scritto tu a mano, ma viene dalla 
decorazione del simbolo glClear che si trova nel .h fornito con la 
OpenGL, puoi stare quasi certo che i programmatori OpenGL l'abbiano 
scritto correttamente, quindi quasi sicuramente il problema � o di 
mancanza della libreria o di decorazione dei simboli.
IMHO la prima cosa da controllare � proprio la corretta indicazione 
delle lib da linkare perch� ci vogliono 20 secondi.
Comunque se guardi bene un po prima probabilmente c'era anche scritto
error LNK2001
vai su google (o su msdn) e incolla LNK2001.
Ottieni:
http://msdn.microsoft.com/it-it/library/f6xx1b1z(VS.80).aspx
lo apri e tra l'altro (tutti i consigli su cosa fare in caso di questo 
errore) trovi:
...
Problemi di compilazione e collegamento
Nel progetto manca un riferimento a un file di libreria (lib) o di 
oggetto (obj). Per ulteriori informazioni, vedere File LIB come input 
del linker.
...
Pi� chiaro di cos� :)

 Pi� chiaro di cos� :)
Gi�, gi�... talmente chiaro che ci hai messo venti e passa righe per 
spiegarlo :-)
Non so se ti rendi conto di quante conoscenze "a monte" hai impiegato 
per spiegare quello che era successo. Il punto � che un problema banale 
(mi manca una lib, ndo sta??) ha richiesto tempo e conoscenze del tutto 
spropositate per la sua soluzione. Ora si pu� anche darmi del 
programmatore della domenica perch� non ci sono arrivato subito, ma 
tutti sono programmatori della domenica, all'inizio... e tanti si 
stufano e lasciano perdere prima di diventare meglio di cos� proprio per 
questo motivo.
E comunque rimane questo interrogativo: perch� tutti i compilatori e 
linker sono programmi batch, quando invece potrebbero sfruttare il fatto 
di avere il programmatore l� davanti e chiedergli cosa voleva dire 
quando ha scritto quella roba strana invece di sparare raffiche di 
errori? Se ci dicesse "La funzione MessageBox vuole un LPCTSTR e invece 
gli hai passato X che � un *CString, che faccio?" gli si potrebbe 
rispondere "Vabb�, svista mia, convertila tu e scrivi il codice che 
serve prima di chiamare la MessageBox" e lui tranquillo modifica il 
sorgente e riparte con la compilazione. Fantascienza? Non mi pare, 
dovrebbe essere una cosa piuttosto fattibile...


GH :) Mi farebbe bene, ammiro la tua calma olimpica 
indifferenza con "quegli altri, di là", devo 
smettere di rispondergli :D


 dovrebbe essere una cosa piuttosto fattibile...
Fattibile ma inutile.
Ripeto: il c++ non si improvvisa. Meglio cos�.
Se vuoi programmare con poco sforzo usa i linguaggi e i framework 4g.
Con quelli *sembra* tutto + facile ... salvo poi che se ad un 
incompetente dai in mano uno strumento "difficile" non produce un tubo, 
viceversa se gli dai in mano uno strumento "facile" � molto probabile 
che produca schifezze.
Per inciso. Il fatto che tutti i tool di compilazione siano programmi 
con interfaccia console (non sono batch) permette di fare un sacco di 
cose utili o utilissime. Tipo automatizzare la compilazione di diverse 
configurazioni che richiedono molto tempo, o ad esempio automatizzare i 
test.
Per esempio quando scrivo librerie, a volte voglio verificare 
semplicemente che certe espressioni siano o non siano compilabili... ho 
scritto un piccolo framework che incapsula il compilatore e permette di 
invocarlo nei miei test case.
Quello che vuoi tu � un buon editor, non un compilatore. Prendi gli 
ultimi VS: compilano sotto il culo mentre scrivi e ti sottolineano gli 
errori come in word... usa il tasto dx e ti fanno vedere gli errori. Con 
l'intellisense ti aiutano a scrivere solo cose sensate. E' vero che le 
funzioni pi� avanzate sono disponibili solo con i linguaggi 4g, mentre 
in c++ o non funzionano o a volte fanno cilecca. Purtroppo la mancanza 
dei metadati nel c++ in questo caso si fa sentire. D'altra parte la 
comunit� c++ non spinge + di tanto per avere tutte queste comodit�...
La tua idea "di avere il programmatore l� davanti" � semplicemente 
folle. Ho alcuni progetti che a compilare impiegano decine di minuti. Ne 
esistono che impiegano ore. Per progetti di un certo tipo, esistono 
server apposta solo per compilare, che magari lavorano di notte con 
nessun programmatore davanti.
Il programmatore ha il cervello: deve spendere il suo tempo a 
programmare, non ad aspettare domande stupide da un compilatore.

 dovrebbe essere una cosa piuttosto fattibile...
senza parole... veramente...
guarda che eclipse su i tipi statici si limita a sottolineare la riga...
il che � gi� tanto... ma te vuoi un ide o una balia?
Magari ipoteticamente potrebbe aiutare un programmatore alle prime armi
ma renderebbe il lavoro frustrante per i programmatori pi� svezzati; c'�
pure chi trova fastidioso l'autocompletamento...
Inoltre dubito che aiuterebbe a diventare un programmatore migliore,
aiuta di pi� seguire l'errore tornare sul sorgente andare a vedere la
firma del metodo e aggiustare i parametri, la seconda volta forse sbagli
di nuovo ma la terza no.
ciauz

 dovrebbe essere una cosa piuttosto fattibile...
mah ... stai sottintendendo che un errore non possa 
nasconderne o generarne altri. Coi template, ad es. spesso 
questo non è affatto vero, e a volte una correzione di un 
errore ne scatena miriadi di altri che erano schermate dalla 
non compilazione di un qualche codice. Finirebbe, in modo 
interattivo, nel premere control break per abortire. Temo eh
ciao
Soviet

 simile. In maniera non tanto dissimile da come si fa con gli header.
...
Per MS guardati #pragma comment
http://msdn.microsoft.com/en-us/library/7f0aews7.aspx
Non � un gran ch� ma meglio di niente...