Newsgroup: it.comp.lang.c++
Titolo: Compilatori a 32 Bit e 64 Bit

Secondo voi quali sono imigliori compilatori per C++
rispettivamente a 32 bit ed a 64 bit ?
Grazie 

 rispettivamente a 32 bit ed a 64 bit ?
Anni fa ho sentito parlare molto bene dei compilatori Intel.
Sempre anni fa, GCC, per quanto molto buono come compilatore C, era 
piuttosto scadente come compilatore C++, ma adesso dovrebbe essere 
migliorato. In particolare, era molto lento a compilare e generava degli 
eseguibili di grande dimensione.
-- 
Carlo Milanesi
http://carlomilanesi.wordpress.com/

 eseguibili di grande dimensione.
La versione 4 del GCC ha migliorato molto il supporto a C++ (LEX\YACC e 
soci non possono generare un parser C++ completo e valido, per cui nella 
4 ne ï¿œ stato scritto a mano uno apposta). La RTTI e i template, che 
prima erano dei grossi punti deboli, sono ora supportati completamente e 
in modo affidabile.
Le compilazioni lunghe e gli eseguibili "grossi", comunque, sono sempre 
lï¿œ... anche se non so quanto possono essere dei veri problemi.
Quanto piï¿œ grosso potrï¿œ essere un eseguibile compilato col GCC? Se uno 
lavora su sistemi embedded avrï¿œ problemi, ma su un normale PC con tutto 
lo spazio disco che c'ï¿œ, non ï¿œ un problema.
Per i tempi di compilazione, se uno ï¿œ abituato a fare piccole modifiche 
e a ricompilare ogni volta diventa pesante, altrimenti non credo che la 
differenza con gli altri compilatori sia tanto sensibile.

 eseguibili di grande dimensione.
anche clang merita di essere testato
http://clang.llvm.org/comparison.html
Mauro

 Secondo voi quali sono imigliori compilatori per C++
La diagnostica del GCC 4.x mi sembra decisamente migliore di quella del 
MS, almeno nella versione 2008. Poi come debugger preferisco di gran 
lunga quello di Visual Studio a tutti quelli che ho provato.
Il realtà la domanda è mal posta. "Migliore" da che punto di vista?
Come ottimizzazione del codice prodotto (Intel credo resti il migliore), 
come reportistica dei warning, come supporto per un IDE?
Nello sviluppo professionale "migliore" ha tanti significati.

 ha scritto nel messaggio 
news:4d1cba46$0$1359$4faf...@reader2.news.tin.it...


 lo spazio disco che c' , non un problema.
Il problema e' la cache: un programma piu' grosso potrebbe incorrere
in maggiore cache miss perche' in un dato spazio di cache ci sta meno
programma, con peggioramento delle prestazioni.
Pleg

      Ma cosa midite del Borland C++ Builder ?
Il vecchio BCC 5.5 (che era alla base di C++Builder 6) è meglio se lo 
lasci perdere, buggatello e supporta male troppe cose. Non compila 
nemmeno le Boost. Nella versione non-free più recente (di Embarcadero e 
non di Borland) non è ancora a livello di VC o di GCC ma non gli sta 
lontano, come supporto allo standard.
Come ambiente di sviluppo invece il CBuilder è ottimo, la VCL è molto ma 
molto comoda; l'help in linea del vecchio C++Builder 6 era magnifico, 
molto chiaro ed esauriente e da neofita mi ci trovai benissimo. Adesso 
l'help delle nuove versioni made in Embarcadero è tipo quello del VC, 
cioè (per me che ero abituato bene) 'na chiavica :-(((

 programma, con peggioramento delle prestazioni.
Problema più teorico che altro, almeno a priori. Un programma a finestra 
sta la maggior parte ad aspettare input.
Che un programma "server" abbia questo problema lo si scopre con il 
profiler. Però, in vita mia, non sono mai arrivato al punto di 
ottimizzare la locazione del codice, (di solito) ci sono prima altri 
colli di bottiglia da limare. Poi tecnicamente la dimensione del codice 
è insignificante. Di solito la gran parte del tempo che un programma 
passa a "macinare" CPU è localizzata in "poche" linee di codice. E sono 
quelle che devono stare in cache. Questo per non usare termini troppo 
tecnici.

 tecnici.
Verissimo, era solo per citare la cosa.
Pleg

 Verissimo, era solo per citare la cosa.
Alla fine le domande come quella che a dato inizio a questo thread mi fa 
venire in mente un'altra mia convinzione. Un programmatore _bravo_ con 
notepad e python darà sempre la paga ad un programmatore _scarso_ con il 
C++ e qualsiasi altro strumento a disposizione. Da tutti punti di vista. 
Come codice mantenibile, prestante, elegante.
Io credo che il fattore umano sia preponderante nella scrittura del 
software. In più credo che i programmatori bravi siano "pochi", nel mondo.
In questo senso non mi preoccuperei troppo di sapere qual'è il 
compilatore *migliore*, anche se il gcc mi piace molto e sarei curioso 
di usare visual studio 2010 e il suo compilatore.

 Come codice mantenibile, prestante, elegante.
Opinione che condivido...
Mi ha fatto una BRUTTA impressione leggere (su slashdot, qualche mese 
fa) che i migliori programmatori di Microsoft _NON_ usano visual C++ né 
visual studio ma sempre e solo tool a linea di comando, cioè il classico 
trio editor/make/cvs (o quel che usano lì) O_O
della serie "se loro che l'hanno fatto non lo usano, perché lo dovremmo 
usare noi? Pagandoci pure sopra per giunta??"


Non sei obbligato ad usarle:-)
E poi la maggior parte dei programmatori di "batteria"
ha come scopo la consegna veloce di un prodotto,
non l' eleganza, ne' l'efficienza ne' le manutenzione
e Visual studio da questo punto di vista e' *perfetto*.
A


in effetti non capisco essenzialmente questa considerazione.
L'IDE comodo serve essenzialmente per sviluppare il codice 
nelle fasi intermedie in modo più rapido. Nessuno proibisce, 
una volta messo a punto il tutto con il RAD, di fare una 
compilazione finale con lo strumento preferito e il maggior 
controllo del make manuale. Ma nel frattempo non vedo la 
ragione per non avvalersi di comodità quali l'intellisense 
(completamenti automatici, elenco membri etc etc).
In effetti dubiterei quasi della dichiarazione riportata, 
magari è una spacconata, boh.
ciao
Soviet

 usare noi? Pagandoci pure sopra per giunta??"
Incuriosito da quanto hai scritto sono andato a cercare l'articolo in 
questione. Non vi ho trovato, però, alcun riferimento al fatto che i 
migliori programmatori Microsoft usino sempre e solo strumenti da linea 
di comando.
Quello che ho letto è che loro non apprezzano la programmazione 
"grafica", ma preferiscono scrivere il codice in modo testuale, cosa che 
non implica affatto il non usare Visual Studio, ma semplicemente il non 
usare i wizard ed i tool grafici che mette a disposizione.
-- 
http://www.econet-project.eu

 strumento preferito e il maggior controllo del make manuale.
 >
Probabilmente hai una fiducia smisurata nel prossimo :-) Io non ne avrei 
il coraggio.

 usare i wizard ed i tool grafici che mette a disposizione.
Per altro per mantenere SQL Server o Office di un wizard non te ne fai 
niente. Poi ci può anche stare che un progetto monstre come quei due la 
compilazione la faccia un team apposta, e che usi dei "banali" makefile. 
Almeno io avevo letto del team di compilazione per i sistemi operativi 
della MS.
Detto ciò devo ancora vedere un ambiente di debug per il C++ che si 
avvicini solamente a quello di Visual Studio. Ad usare gdb a riga di 
comando a me viene l'orticaria. Ma dall'altra parte ho colleghi (be 
diciamo uno solo collega) che usano principalmente WinDebug e programmi 
compilati in release per fare debug. Ognuno è fatto a modo suo.


premetto che non ho proprio capito il commento ... forse 
perché non ho mai alcuna relazione col prossimo in merito 
alla programmazione (scrivo solo x hobby e per me medesimo).
Cmq, a parte la diversa estrazione, mi spiegheresti cosa 
volevi dire ? Non riesco a dedurlo
ciao
Soviet

 comando a me viene l'orticaria.
Premetto che:
1. condivido la tua posizione: in un debugger qualche tipo di
interfaccia utente piu' ricca di un interprete di comandi e' davvero
comoda
2. Ovviamente il confronto lo dovresti fare con qualche tool *sopra*
gdb.
Aggiungo... a me risulta che fino a poco tempo fa le capacita' di gdb
(chiamare metodi e funzioni al volo) mancassero sotto MS. Io, che faccio
uso piuttosto ampio di metodi std::string str() const e simii trovo la
cosa parecchio comoda (la cosa imbarazzante quando si confronta ad un
IDE Java, ma li e' per "merito" di Java -- sigh, come sono caduto in
basso a parlare di meriti di Java --).
Per esempio sebbene il resto dell'IDE mi facesse abbastanza cacare,
XCode ha un ottimo sistema di debug (io usavo cmake con cui mi alternavo
fra project per XCode per il debug e makefile per il resto).
Emacs mi ricordo avesse un ottimo rapporto con gdb, ma potrei sbagliare.
Inoltre sono convinto che in troppi abbiamo speso troppo poco tempo per
capire come usare per bene gdb. Mi metto come primo della lista, eh. 
-- 
- riko
http://www.enrico-franchi.org/
http://rik0-techtemple.blogspot.com/

 (chiamare metodi e funzioni al volo) mancassero sotto MS.
Ci sono, ci sono. Anche se non ci sono abituato.
Comunque è sulla libreria standard che il debugger MS mi sembra 
superiore. Poi sulla compilazione sono un po' perplesso, visto che MS 
ignora il codice template non usato, mentre il GCC "controlla" almeno la 
sintassi tutto il codice template, a prescindere che sia effettivamente 
usato o meno.

 usato o meno.
Interessante. Impatto sulle performance (di compilazione)?
Se si sente, potrei anche essere disposto.
-- 
-riko
http://www.enrico-franchi.org/
http://rik0-techtemple.blogspot.com/

 Se si sente, potrei anche essere disposto.
Se usi i template l'impatto c'è, è che almeno con la versione 2008 la 
gestione dei warning mi sembra superiore, e di molto, nel gcc. Ho perso 
un paio di giorni per scoprire che un errore sui parametri passati per 
riferimento e segnalato dal gcc, ma non dal MS, era a rigore di standard 
un errore ben segnalato.
Ecco, il GCC mi sembra molto vicino a fare le cose giuste. Il MS mi 
sembra molto orientato al mondo produttivo. Ottimo debugger, veloce a 
compilare, opzioni pragma sensate, ma lo standard non è una priorità. 
Almeno fino al 2008. Sul 2010 non so se hanno aggiustato il tiro.
Per esempio, il "banale" make sfrutta tutti i processori per compilare, 
o fa un file alla volta? Visual Studio compila con tutto l'hardware che 
riesce ad usare, per esempio.
Poi a me farebbe comodo compilare con un cluster di PC, e quello nella 
versione professional di visual studio non c'è.

 usato o meno.
Potresti, per cortesia, chiarire meglio cosa intendi?
TIA
-- 
http://www.econet-project.eu

 versione professional di visual studio non c'č.
Per farlo con un cluster di mac e' banale all'ennessima (grazie ad
xgrid). Non prenderei comunque un cluster di mac solo per questo. Pero'
convincere il reparto acquisti che i commerciali e i grafici hanno
*bisogno* di un mac e poi usarli surrettiziamente per clusterizzarti le
compilazioni non e' da sottovalutare. ;)
Comunque se hai voglia di sbatterti IMHO ce la si fa abbastanza
facilmente a mettere su l'infrastruttura con Linux. Con "facile"
dipendente da quanto hai familiarita' con il grid.


 Potresti, per cortesia, chiarire meglio cosa intendi?
template <typename T> T pippo(T t){ return T/0;}
non è detto che venga compilato mai con il MS, se pippo non è mai 
richiamata la funzione "pippo". Con il GCC invece, ove possibile, una 
compilazione parziale c'è. Almeno la sintassi viene controllata.
L'esempio è cretino e forse non è quello giusto, ma me ne sono accorto 
per un errore in una classe che avevo scritto, e mai usata in tanti anni 
di MS. Quando ho fatto il porting, boom, errore di compilazione.


Sviluppo sotto windows, e al massimo compilo sotto Linux. Però il grid 
me lo sono scritto da solo, anche se non è adatto per fare compilazione, 
Ma ci penso su.


L'esempio e' giusto, nel senso che, se non si istanzia mai tale 
template, Visual C++ non segnala errore, mentre con GCC genera un errore 
bloccante.
E' pero' fuorviante la divisione per zero, che ovviamente non viene 
segnalata da nessuno dei due compilatori. Un esempio migliore sarebbe stato:
   template <typename T> T pippo(T t){ return T/2;}


 di MS. Quando ho fatto il porting, boom, errore di compilazione.
Ok, ho capito cosa intendevi.
Non essendo mai istanziato è corretto che non venga compilato (e neppure 
il GCC lo compila), però il comportamento giusto è quello del GCC, 
perché questo tipo di errore sintattico andrebbe segnalato (altri tipi 
di errori sintattici è invece corretto che non vengano rilevati).
C'è da dire che il mancato rilevamento di quest'errore non è 
fondamentale, proprio perché la funzione non era utilizzata. Se avessi 
provato a chiamarla, istanziando quindi il template, anche il VC++ si 
sarebbe lamentato, facendoti scoprire l'errore.
Ciao.
-- 
http://www.econet-project.eu

 Ma ci penso su.
Quindi direi che il problema lo sai risolvere ampiamente! :)
Penso che bisogna solo stare un po' attenti alle dipendenze, poi per il
resto dovrebbe funzionare bene. 


 bloccante.
Appunto il gcc "perde tempo" per una cosa che non serve visto che la 
funzione non sarà istanziata, anche se personalmente preferisco il 
comportamento del gcc.

 resto dovrebbe funzionare bene.
Forse con qualche martellata in python si potrebbe suddividere al volo 
il makefile in tanti pezzi, e poi farli eseguire su macchine diverse. 
Forse non è nemmeno una cosa tanto difficile, e sarebbe portabile.
Ci penso su, anche se immagino che una cosa del genere interessi solo me.

 Ci penso su, anche se immagino che una cosa del genere interessi solo me.
Direi di no...
Ah, fra i vari:
http://code.google.com/p/distcc/
http://docs.sun.com/source/819-0506/dmake.html


 IMHO non e' la strada per cui andare.
Grazie di tutti i link. Ci darò una occhiata.
Ho visto nei sorgenti di distmake che esiste una versione windows  non 
menzionata nella documentazione ufficiale.
http://distmake.sourceforge.net/pmwiki/pmwiki.php?n=Main.QuickStart
Alla fine però credo che lascerò perdere, immagino che non sia cosa in 
cui sia possibile spenderci poco per essere "produttivi".

 cui sia possibile spenderci poco per essere "produttivi".
distcc mi risultava facile... 


 distcc mi risultava facile...
Sotto linux, mentre a me fa comodo sotto windows. Poi devo chiedere l'ok 
per avere dei computer da usare al bisogno, anche se sarebbe il problema 
minore. Poi scoprire se si può generare un makefile in modo 
relativamente semplice sotto Visual Studio. Poi testare.
Alla fine della fiera sono pagato a giornate, e se dico che "perdo" 
anche solo mezza giornata per una cosa del genere mi sparano.

 finale con lo strumento preferito e il maggior controllo del make manuale.
(Thread 02/01/2011 12:08)
stai suggerendo, per il buid finale di un progetto, di sostituire il 
compilatore su cui si è sviluppato e testato con un altro: il preferito.
Personalmente credo che ci sia un'alta possibilità di trovarsi di fronte 
a comportamenti del programma inattesi. Per questo non lo farei mai; 
nemmeno con un aggiornamento dello stesso compilatore.
Saluti.

 aggiornamento dello stesso compilatore.
per me è stata una certezza.... già provato e passatoci.
Mai più.
-- 
Un corpo immerso in un liquido si bagna.
Un corpo immerso nel cemento sapeva troppo.
Un corpo immerso in un altro corpo si diverte.
Un corpo immerso in due corpi è un'orgia.

 trio editor/make/cvs (o quel che usano lì) O_O
Ad aprile 2008 sono stato al Microsoft Development Center di
Copenhagen. Parlando con uno dei loro Program Manager, gli ho chiesto
se stessero usando C# o qualche altro linguaggio .NET per lo sviluppo
di Dynamics (l'applicazione MS che sviluppano in quel centro). Sguardo
smarrito, balbettìo: ahem... no, not really.
Verrebbe da chiedergli: ma se 'sti linguaggi non li usate voi, perché
dovremmo usarli noi? :))

 dovremmo usarli noi? :))
Bella domanda.