Newsgroup: it.comp.lang.c++
Titolo: Scelta del compilatore

Ciao a tutti,
devo sviluppare un programma abbastanza grosso e con molta matematica
con visual C++.
Fin'ora ho usato una versione del borland un po' vecchia.
Vorrei cambiarlo, prenderne uno piú attuale, ma non so cosa scegliere.
Se scelgo qualcosa diverso dal borland (tipo visual studio) devo
cambiare molto codice.
Ma il criterio principale per scegliere non é tanto il dover o meno
modificare il codice, bensì scegliere qualche compilatore che dia
buone prestazioni e che continui a funzionare anche con le future
versioni di Windows (io ora ho windows 2000).
Qualcuno mi saprebbe dare un consiglio e darmi qualche indicazione sui
pro e contro sulla scelta di un compilatore piuttosto che un altro?
Grazie a tutti!
Paola

paola ha scritto:

Ciao,
non riesco a capire in che senso ritieni di dover cambiare molto codice.
Il punto e' che se passi da un compilatore vecchio ad uno 'nuovo' 
sicuramente c'è del codice che devi cambiare (per una questione di 
affinita' allo standard, mi viene da pensare) e non credo che tale 
quantita' vari in funzione del compilatore che scegli.
Inoltre, tieni presente che potresti approfittare dell'occasione per 
correggere il suddetto codice e renderlo più 'portabile' (a me spesso e' 
capitato di dovere sviluppare alcune applicazioni con interfaccia, e 
lavorando - almeno fino al 31 dicembre - in un istituto di ricerca, dopo 
una prima terribile esperienza con le MFC, ho imparato a scrivere 
applicazioni facendo attenzione ad aderire il piu' possibile allo 
standard, utilizzando oltretutto la libreria multipiattaforma fox per le 
interfacce. Beneficio di questo e' stato che quando mi hanno detto 'ok 
passiamo a Linux', l'ho fatto in un giorno :) ed il tempo che ho perso 
l'ho perso per fare funzionare anjuta ).
Per quanto riguarda le prestazioni, beh si' e' vero il compilatore, ma 
li' dipende tanto anche da come implementi gli algoritmi numerici, ma 
sicuramente lo saprai meglio di me... ;)
Forse non ho colto il senso della tua preoccupazione di cambiare codice 
e del motivo di cio', se ho cannato fammi sapere.
Ciao,
Bruno

Ciao Bruno,
grazie per la risposta.
Cambiare codice non è una preoccupazione, anzi effettivamente, come
dici tu,  è l'occasione per migliorarne alcuni aspetti.
Quello che non mi è chiaro sono piuttosto i vantaggi e svantaggi che
posso avere scegliendo un compilatore piuttosto che un altro.
Avresti mica qualche suggerimento?
Grazie
Paola

paola ha scritto:
[ cut ]
Ciao Paola,
visto che stai parlando di usare C++ *standard* mi viene da pensare che 
trattandosi di algoritmi numerici probabilmente l'analisi del 
compilatore (o meglio delle ottimizzazioni che puoi richiedere di fare) 
e' uno soltanto degli aspetti da tenere in mente, gli altri potrebbero 
essere l'architettura target ( certo il compilatore dovrebbe astrarre il 
tutto, ma per algoritmi numerici potrebbe non bastare, credo) oppure il 
modo con il quale hai programmato il tutto (pensiamo ad i template ed a 
come vanno tradotti in linguaggio di basso livello dal compilatore).
Fondamentalmente l'adozione di codice standard dovrebbe ridurre di molto 
la comparazione dei compilatori, almeno se usi gli ultimi (vc++ 8 ad 
esempio, oppure l'ultimo gcc ).
Poi magari ti risponde qualcuno che ha esperienza di 'lavoro' nella 
scrittura di algoritmi numerici...
Ciao

 esempio, oppure l'ultimo gcc ).
Ovviamente intendevo che l'adozione di codice standard dovrebbe ridurre 
di molto *l'utilita'* della comparazione dei compilatori...
Sono arrivato al punto da quotarmi da solo :|
Pessimo inizio questo 2006...

paola ha scritto:

Posso solo dirti di usare il GCC 3.4 invece del GCC 4.0, che è meno 
efficiente. Per il resto, vedi tu... Puoi anche provare il Watcom C++ 
che ora è scaricabile liberamente, ai suoi tempi era un fulmine di 
guerra, ma non so quanto sia standard... mi sa che da questo punto di 
vista non regge il confronto con gli altri.

 Grazie a tutti!
Prego
Ciao

 l'ho perso per fare funzionare anjuta ).
Il tuo discorso sulle librerie multipiattaforma non fa una piega, ma 
tieni conto che c'e' l'altra faccia della medaglia, ovvero:
1. Se usi una libreria nativa come MFC per Windows hai un'applicazione 
piu' efficiente rispetto all'uso di un ulteriore strato software 
costituito da una lib multipiattaforma
2. Se usi MFC puoi integrarti a pieno con Windows e con il Win32 SDK, 
sfruttando le potenzialita' di Windows al 100% (cosa impossibile con una 
lib multipiattaforma, per definizione).
3. Il Visual C++ (almeno nelle versioni 6 e 2003) fornisce un ottimo 
supporto alla programmazione MFC, grazie a vari menu e ClassWizard.
Secondo me, la vera strategia vincente e' quella di isolare nel proprio 
programma le classi che gestiscono la GUI da quelle che costituiscono il 
core dell'applicazione. Ad es. un'applicazione matematica avra' classi 
per gestire matrici, vettori, etc. Queste classi saranno scritte in C++ 
*standard* (ad esempio, in questo codice non userai CList di MFC, ma lo 
standard std::list), e si ricompilano come niente su una qualsiasi 
piattaforma ove sia presente un compilatore C++ aderente allo standard.
Le classi GUI andranno riscritte per la nuova piattaforma.
Ciao

Kobe ha scritto:

Quoto in pieno, e' ovvio che e' anche importante sapere quanto e' 
confidente con le MFC (almeno perche' sono quelle relative al tuo esempio).

 guerra, ma non so quanto sia standard...
afair non ci ha manco std::set.
-- 
L'idiozia trascende il mezzo con cui viene espressa.

 Le classi GUI andranno riscritte per la nuova piattaforma.
Cioé mi devo reimplementare un toolkit portabile? Perché non usarne uno già
pronto?
Per come la vedo io una strategia interessante é avere una GUI in un
linguaggio interpretato, con estensioni in c++ ove necessario.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail** 
-<! Living on Earth may be expensive, but it includes an annual free trip
		around the Sun. !>-

 linguaggio interpretato, con estensioni in c++ ove necessario.
Tutto dipende da cio' che devi fare. Per tool veloci basta pure Visual 
Basic (che va bene anche per cosette piu' grandi). Poi pero' voglio 
vedere qualcuno che scrive un'applicazione come Office in un linguaggio 
interpretato :) ...senza richiedere quantita' astronomiche di memoria, 
hard-disk, CPU...
Poi tutta questa moda della programmazione "facile", linguaggi alla 
Python o Java senza puntatori, secondo me non porta molto avanti: sento 
parlare male di un IDE (Eclipse, se non erro) scritto in Java, e che e' 
un mostro di pesantezza (sei costretto a riavviarlo dopo un certo numero 
di ore di lavoro, richiede molte risorse, etc. Microsoft Visual C++ 6 e' 
una scheggia a confronto!).
...Nessun garbage collector automatico sara' meglio di un bravo 
programmatore C++ che sa come gestire la allocazione dinamica della memoria.
K

 Python o Java senza puntatori, secondo me non porta molto avanti
Non ti sembra una tesi un po' insostenibile?
xpfup


 programmatore C++ che sa come gestire la allocazione dinamica della memoria.
Speriamo. Sennò qua ci tocca cambiare mestiere.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! A mathematician is a device for turning coffee into theorems. !>-
                P. Erdos