Newsgroup: it.comp.lang.c++
Titolo: tempo esecuzione semplice ciclo in c++ e c#

Ho provato ad eseguire un numero grande di cicli for in cui si esegue
una moltiplicazione e una divisione:
1) in c++
2) in c#
3) da una dll scritta in c++, ma passando a c# i risultati a
attraverso "PInvoke"
I risultati sono stati che il ciclo viene completato su di un vecchio
pc in:
1) circa 38 secondi
2) circa 33 secondi
3) circa 50 secondi
Qualcuno mi sa spiegare i motivi per cui ottengo questi risultati?
Premetto che il c++ non lo conosco bene ed ho scritto poche linee di
codice solo per fare questo esperimento.
            float Ti= clock(); //  Tempo iniziale
            double x = 1.05;
            for (int var_contatore=1; var_contatore < 1400000000;
var_contatore++)
          {
                    x = x * 1.000011564;
                    x = x / 1.000011562;
          }
           float Tf= clock(); //  Tempo finale
           float TempoAccumulato = Tf -Ti; // tempo conteggiato dal
reset
           cout << "x=" << x;
           cout << "t=" << TempoAccumulato;
  Giuseppe

 cout << "t=" << TempoAccumulato << endl;
Ricorda << endl altrimenti non puoi leggere i dati...
Per quanto mi riguarda, sulla mia macchina (Intel Core Duo 2.66 GHz) con
G++ 4.1.2, Linux SuSE 10.2, ho ottenuto i seguenti risultati:
Con la tua versione: 29 secondi netti
Con le mie modifiche: 29,05 secondi
Il che vuol dire che G++ ha fatto da solo l'ottimizzazione per il
contatore, per esempio.
Aggiungendo l'opzione di ottimizzazione -O3, passo a 25,8 secondi.
Ciao,
- -Federico
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - 
http://enigmail.mozdev.org
iD8DBQFIoXdZBIpu+y7DlLcRAnj3AKCSJo56XTr+C3fdxceQqTWy2788FwCdGffG
6SQjT605Wj93bSx3rdkfYHw=
=XPR6
-----END PGP SIGNATURE-----

 Qualcuno mi sa spiegare i motivi per cui ottengo questi risultati?
Non capisco che cosa tu voglia sapere nello specifico. Tieni presente
che test di questo tipo hanno poco senso, specie se eseguiti una sola
volta. Andrebbero fatti su larghissima scala, calcolando le medie dei
tempi ottenuti. E comunque bisogna assicurarsi che la CPU non sia
impegnata in altre attività (il che è pressoché impossibile da
controllare), che non ci siano ottimizzazioni di vario tipo a vari
livelli (comprese le cache del processore, il che è ugualmente
impossibile da controllare), che non ci siano swap tra memoria e
disco, eccetera eccetera eccetera. Insomma, se non hai un controllo
pieno del contesto dell'esperimento avrai sempre una certa
(abbondante) indeterminazione.

 Qualcuno mi sa spiegare i motivi per cui ottengo questi risultati?
e questo dovrebbe metterci ancora meno...
const double k=1.000011564/1.000011562;
double x = 1.05;
float Ti= clock(); //  Tempo iniziale
for (int i=1; i < 1400000000;++i) x *= k;
float Tf= clock(); //  Tempo finale
float TempoAccumulato = Tf -Ti; // tempo conteggiato dal reset
cout << "\nx=" << x << " t=" << TempoAccumulato/CLOCKS_PER_SEC << "s";
penso che dipenda dalle ottimizzazioni che i vari compilatori aggiungono 
al codice.
Il codice di partenza non è per nulla ottimizzato e quindi obbliga la 
CPU a compiere operazioni costose e inutili.
I compilatori (con le giuste opzioni) si accorgono di alcune cose che 
possono essere sistemate in fase di compilazione per ottimizzare le 
prestazioni, l'uso della memoria o le dimensioni del risultante codice.
Dipente però dal compilatore, dalle opzioni e anche dallo stesso codice 
(da quanto cioè può essere ottimizzato).
Per i motivi che ti hanno già ricordato e per questi, il tuo test non è 
molto significativo.
Più che il linguaggio di programmazione (la cui scelta è comunque 
importante) quanto del compilatore, la cosa migliore è scrivere buon codice.
ciao.

 (abbondante) indeterminazione.
Che il "test", se così si può chiamare, fosse poco significativo in
effetti lo immaginavo.
Però forse qualche idea ad uno non molto esperto di programmazione può
darla.
Dalle risposte che ho ricevuto evidenzio che l'ottimizzazione del
codice è molto importante.
Forse il compilatore di c# alcune di queste operazioni le fa in
automatico?
Comunque almeno l'impressione di lentezza e pesantezza del .net
potrebbe essere smentita.
In rete ho trovato un test più serio del mio:
http://www.grimes.demon.co.uk/dotnet/man_unman.htm
Per me, vista la maggiore semplicità del c#, già il fatto che abbia
prestazioni simili sarebbe un buon risultato.
Attenzione, non voglio scatenare guerre di religione tra linguaggi!
Ho scritto qua perchè pensavo di avere più probabilità di trovare
gente che conoscesse entrambi i linguaggi rispetto ad un NG sul c#.
Rispetto al punto 3), la lentezza non credo che sia un caso, qualcuno
sa darmi una spiegazione?
     Giuseppe

 questi e con un ciclo cosě semplice potrebbe contare qualcosa.
Nah, non con un int.
E' una regola che tipicamente vale per le classi (fosse ad esempio un 
iteratore).
  bye
	av.

 controllare),
E' la prima cosa che mi e' venuta in mente.
Per questo, pur sapendo che rimangono ben altri limiti alla validita' 
del risultato, invece che conteggiare il tempo trascorso all'interno del 
programma stesso, mi affiderei ad utility esterne.
Per esempio, su sistemi POSIX, con
time mioprogramma
ti da, oltre che il tempo impiegato (che variera' anche in funzione 
degli altri programmi che stanno girando), anche il tempo di esecuzione 
attribuibile in modo specifico al tuo programma (che e' gia' un po' piu' 
indicativo).
Potrebbe pertanto risultarti una volta un totale di 60 secondi, dei 
quali 45 utilizzati effettivamente dal tuo programma e, la volta dopo, 
80 secondi, di cui 46 attribuibili al tuo programma.
Insomma, non e' la soluzione totale, ma riduci di parecchio i fattori 
esterni.
  bye
	av.

 sa darmi una spiegazione?
Sicuramente stai facendo dei passaggi in piu'.
  bye
	av.

 potrebbe essere smentita.
In realtà, tecnicamente non c'è ragione di credere che i linguaggi
distribuiti con .NET siano più lenti, se compilati Just-In-Time. Anzi,
direi che vale addirittura l'opposto: in teoria un programma compilato
JIT ha più possibilità di sfruttare l'hardware specifico su cui sta
girando. Poi, concorrono comunque altri fattori a rendere più lento il
codice, come la gestione differita delle risorse (garbage collector,
reference count, ecc...).

 Stai smentendo la lentezza, non la pesantezza.
Io non capisco bene a cosa ci si riferisca con "pesantezza". Cioè, se
non incide sui tempi di calcolo, non la riterrei una "pesantezza". Si
sa che tutto ciò che è pesante è lento perché pesante :-)... ma se non
è così...
Penso ci si riferisca all'invasività di .NET. E non posso dare torto
in questo senso. Il fatto che questo possa o meno essere un problema
dipende dai contesti. Certo è che ora come ora c'è un marasma di
versioni beta di molti prodotti, nell'orbita .NET, che si pestano i
piedi a vicenda in maniera terribile. Spero che MS metta a posto le
cose al più presto.

 Penso ci si riferisca all'invasività di .NET.
Non capisco cosa tu intenda.
  bye
	av.
P.S. Credo stiamo andando un po' troppo OT...

Usando *= e /= magari ti riesce un pochino più veloce
A meno di non considerare oggetti (e quindi eventuali costruzioni
temporanee) quelle di incremento dovrebbero essere operazioni
equivalenti e così pure le forme contratte di moltiplicazione e
divisione rispetto a quelle espanse.


Per contro perche' l'ottimizzazione JIT valga la pena deve superare il
proprio stesso costo. Sempre in teoria la compilazione anticipata con
ottimizzazione guidata dalla profilazione potrebbe avere i vantaggi
della compilazione JIT senza averne gli svantaggi.
Ciao,
Nicola

 della compilazione JIT senza averne gli svantaggi.
Jeffrey Ritcher, già sei anni fa affermava: "Many developers
(especially C/C++ developers) are concerned about JIT compilation
because the end-user's machine is compiling code on the fly, hurting
the application's overall performance. I used to be very concerned
about this performance cost as well, but having written, built, and
used many managed assemblies for several years now, my experience has
been that the performance loss due to JIT compiling is not that great.
In fact, I believe that JIT compiling is awesome and is capable of
producing code that is more efficient and more optimized than a
compiler that produces native CPU instructions"
http://www.codeguru.com/Csharp/.NET/net_general/toolsand3rdparty/article.php/c4651

 compiler that produces native CPU instructions"
http://www.codeguru.com/Csharp/.NET/net_general/toolsand3rdparty/arti.
..
Torno a dire: con la compilazione guidata dalla profilazione
*teoricamente* non c'e' informazione disponibile al JIT che non sia
disponibile anche al compilatore tradizionale, in termini di dove e di
come ottimizzare, salvo che, di nuovo, *teoricamente* il JIT potrebbe
avere un approccio piu' adattivo, ovvero compilare diversamente in
funzione di mutate caratteristiche di esecuzione.
Temo che alla fine della fiera questo sia un altro argomento dove le
conclusioni di carattere generale tendono a lasciare il tempo che
trovano e conviene ragionare caso per caso. Non solo, ma mi pare che
anche costruire casi seriamente confrontabili sia piuttosto complesso.
Ciao,
Nicola


Comunque dovreste essere tutti d'accordo che per un principiante come
me l'esistenza di java (che non conosco) e del .Net sia
provvidenziale.
      Giuseppe

provvidenziale.
Per quale motivo?

On 13 Ago, 19:52, Andrea Laforgia

perchè per ottimizzare codice scritto in c++ c'è bisogno di una
conoscenza approfondita del funzionamento del linguaggio, mentre
utilizzare c# mi sembra sia molto più semplice e, in molti casi, si
possono ottenere le stesse cose.
purtroppo un limite è che il codice è facilmente decompilabile da
chiunque.
     Giuseppe


Un principiante dovrebbe preoccuparsi di imparare a scrivere codice
corretto e ben disegnato, piuttosto che di ottimizzare il codice.
L'eventuale vantaggio e' piuttosto dato dalla maggiore semplicita' di
Java e C# e dal fatto che le librerie te le trovi gia' li' belle e
pronte, senza dovertele cercare in giro.
Dal punto di vista del controllo delle prestazioni il C++ ha
un'infrastruttura molto piu' solida, che viene fuori al complicarsi
dei problemi che affronti.
Ciao,
Nicola

 chiunque.
Mi sembra che i limiti siano ben altri (mancanza in pratica di 
portabilita', richiesta di risorse, ecc...).
  bye
	av.

 conoscenza approfondita del funzionamento del linguaggio,
La conoscenza approfondita di un linguaggio è essenziale per
programmare, in generale, non per ottimizzare.
Ottimizzare è un'attività molto difficile da svolgere manualmente.
Sicuramente è meglio affidarsi all'implementatore del linguaggio.
L'importante è saper scrivere codice efficiente, ovvero non
palesemente inefficiente.
C# e C++ sono solo parzialmente equiparabili. Esistono contesti in cui
non si potrebbe usare C#. Io ho partecipato spesso allo sviluppo di
middleware che giravano in ambiente Unix (che è l'ambiente naturale di
sviluppo per C/C++), che si occupavano di integrazione tra sistemi
differenti e che dovevano rispondere a requisiti di performance BEN
precisi. Ti assicuro che non c'è alternativa al C++ se scegli un
linguaggio che garantisca performance di un certo livello e al
contempo ti fornisca gli strumenti giusti per modellare ad un livello
sufficientemente alto il dominio dell'applicazione. Di solito
qualunque sviluppo di applicazioni server che debbano garantire ottime
performance non lascia molta strada ad alternative al C++.

 corretto e ben disegnato, piuttosto che di ottimizzare il codice.
Concordo pienamente...
L'esempio che faccio può apparire paradossale ma quello che capita a 
volte a programmatori dilettanti è di "ammazzarsi" ad ottimizzare un 
bubble sort quando esistono algoritmi ben più efficienti.
A parte il paradosso, spesso si tenta di ottimizzare algoritmi 
inefficienti quando invece è proprio su questo che si deve lavorare.
Un programma scritto bene andrà veloce con qualsiasi linguaggio, anche 
se forse non sarà proprio così efficiente come se fosse scritto in 
assembly (tanto per fare un esempio)

assembly (tanto per fare un esempio)
C'è da dire che oggi nessuno più scrive direttamente in assembly e
questo perché il lavoro delle applicazioni è sicuramente molto più
complesso oggi, rispetto a un tempo e poi perché, con tutta
probabilità, si finirebbe per scrivere del codice meno efficiente di
quello prodotto da un compilatore.

 Qualcuno mi sa spiegare i motivi per cui ottengo questi risultati?
Probabilmente, la versione C++ è più lenta perche' non hai attivato le 
ottimizzazioni di codice del compilatore C++, che dipendono dal compilatore.
Per il compilatore Microsoft, compilando dalla riga di comando, usa 
l'opzione "/Ox".
Non so perche' usando la "PInvoke" e' piu' lento.
Ma la chiami una volta sola per tutta l'esecuzione?
-- 
     Carlo Milanesi
 
http://digilander.libero.it/carlmila

 Ma la chiami una volta sola per tutta l'esecuzione?
Ho provato in due modi:
 1) chiamata un'unica volta ed esegue lo stesso codice che esegue in
c#, ma è più lento
 2) cambio il codice c++ dividendo il numero delle iterazioni per 100,
ma poi faccio 100 chiamate alla funzione. I tempi sono grosso modo gli
stessi. Quindi sembrerebbe che il ritardo non derivi dalla chiamata,
ma dal fatto di eseguire il codice da dll esterna.
l'argomento mi interessa, perchè se fosse sempre più lenta la
chiamata, questo mi precluderebbe la possibilità di utilizzare codice c
++ da c# tutte le volte che sono richieste buone prestazioni.
     Giuseppe

 ma dal fatto di eseguire il codice da dll esterna.
Questo e' un argomento dipendente dal framework .NET, che esula da 
questo newsgroup.


 quello prodotto da un compilatore.
L'esempio dell'assembly è emblematico e non era citato a caso.
Teoricamente dovrebbe essere il programma direttamente scritto in 
linguaggio macchina (praticamente quello scritto con un assembler) il 
sistema migliore per ottenere il 100% dalle prestazioni da un sistema: 
massima efficienza, massime prestazioni.
Ma in pratica un buon programma in C/C++ non teme il confronto (almeno 
per quanto riguarda le prestazioni), anzi è facile che le complicazioni 
che il programmatore assembly deve affrontare producano inefficienze.
Tant'è che l'assemlber si usa soltanto per casi particolari e isolati.
Comunque secondo me alcuni si fanno prendere da una vera e propria ansia 
da prestazioni: mica tutti scrivono software come videogiochi, 
applicazioni real-time, calcolo scientifico, etc.
Per la maggior parte delle applicazioni che un dilettante scrive (non 
parlo di professionisti al lavoro) certe ottimizzazioni spinte secondo 
me lasciano il tempo che trovano... diverso invece è usare una ricerca 
binaria invece di una lineare, quindi algoritmi appropriati e strutture 
dati appropriate.
ciao.

 applicazioni real-time, calcolo scientifico, etc.
Anche in questi casi, molti dei framework alla base sono già belli e
pronti.

Uso dev++, e compila e fa tutto lui.
Anche con Dev è possibile impostare le opzioni del compilatore.

 dati appropriate.
Non se ti riferissi anche a me (visto che il thread l'ho iniziato io e
le preoccupazioni per le prestazioni le ho comunicate io), comunque
quando il dilettante deve scrivere un programma che elabora immagini
in tempo reale le prestazioni contano eccome.
Anche perchè può darsi che il dilettante sia tale in programmazione c+
+, ma nel campo in cui vuola fare ricerca.
   Giuseppe

GiuseppeDini ha scritto:


Non mi permetterei mai di definirti dilettante,tant'è che nemmeno ti 
conosco e non ho dubbi che tu sia in grado di scrivere programmi 
particolarmente complessi.
Mi spiace, ci siamo capiti male... Io non ho mai fatto riferimento a 
nessuno in particolare.
Il mio era un discorso generale, dato che questi thread infiammano 
sempre un pò tutti... e non tutti scrivono il tipo di programma che devi 
scrivere tu, ma un pò tutti si preoccupano della velocità d'esecuzione 
del codice... anche troppo il più delle volte.
Nel tuo caso è invece importante, ma questo si evinceva già dai miei 
post precedenti.

 post precedenti.
ok.
   Giuseppe

   Giuseppe
Non ci capisco più niente!
Ho installato "codeblock" e provato a compilare con le varie opzioni
O-1, O-2, O-3.
I risultati sono molto interesanti.
Adesso il tempo di esecuzione per il c++ è di 24 secondi, quindi
meglio del c#, e il tempo della dll richiamata dal codice c#
attraverso PInvoke è addirittura di 21 secondi.
Quest'ultima è la cosa più strana.
       Giuseppe

 sa darmi una spiegazione?
Non hai postato il codice della versione .dll, suppongo che il loop 
fosse in C# e le operazioni matematiche nella DLL, quindi ci sarebbero 
1.400.000.000 invocazioni della DLL che significano perlomeno 
altrettante operazioni di salto e probabilmente di save/restore dello 
stato dei registri sullo stack. I salti danneggiano la pipeline del 
processore e le operazioni sullo stack toccano, potenzialmente, la 
memoria, di conseguenza la maggior lentezza.
Bye,
  Gabry


Che ci siano innumerevoli campi d'applicazione dove le prestazioni
sono importanti e' indubbio. Il punto pero' e' come il principiante
puo' spendere il suo tempo nel modo piu' proficuo.
Intanto bisognerebbe intendersi sul termine principiante: esperto
informatico che non conosce il C++? Persona abituata al ragionamento
scientifico, competente in matematica, ma digiuna di informatica?
Studioso di materie umanistiche senza basi di ragionamento formale?
Ribadisco, per scrivere codice efficiente bisogna avere delle basi
teoriche, per sapere con che criterio scegliere gli algoritmi da
utilizzare; conoscere bene il linguaggio per poterne sfruttare a fondo
le potenzialita'; avere delle basi di disegno del software, perche'
l'organizzazione del programma influisce profondamente sulla sua
modificabilita' e quindi sulla possibilita' di ottimizzarlo senza
perdercisi dentro.
Nota che non ho ancora parlato delle competenze necessarie per
procedere all'ottimizzazione vera e propria: senza le basi di cui
sopra partire ad ottimizzare diventa sostanzialmente una pura
questione di fondoschiena. Per ottimizzare invece bisogna conoscere
bene le caratteristiche dei propri strumenti: computer, sistema
operativo, compilatore, librerie, *profilatore*.
Non so a che punto sei tu, ma a mio avviso il percorso e' questo.
Ciao,
Nicola

 cout << "\nx=" << x << " t=" << TempoAccumulato/CLOCKS_PER_SEC << "s";
Pensando così allora questo è ancora più rapido:
const double k=1.000011564/1.000011562;
double x = 1.05;
float Ti= clock(); //  Tempo iniziale
x *= pow(k,140000000);
float Tf= clock(); //  Tempo finale
float TempoAccumulato = Tf -Ti; // tempo conteggiato dal reset
cout << "\nx=" << x << " t=" << TempoAccumulato/CLOCKS_PER_SEC << "s";
così deve eseguire solo una moltiplicazione visto che pow(k,140000000) è 
una costante. Forse il problema della domanda iniziale non sta tanto 
nell'ottimizzare il codice, quanto nel fare una prova di efficienza tra 
linguaggi.


Il discorso è che eseguire codice nel minor tempo possibile spesso può
dipendere più dal tipo di applicazione che si vuole ottenere che
dall'esperienza del programmatore in quel linguaggio.
Conosco molti ottimi programmatori che sono letteralmente sprecati a
programmare semplici gestionali per piccole e medie aziende che
richiedono prestazioni non eccezionali.
Qua contestavo più che altro l'opportunità di preoccuparsi delle
prestazioni, che non è detto che siano preoccupazioni inutili da
principianti (tipo i ragazzini che vogliono l'auto che raggiunge
velocità massime elevatissime, anche se non le raggiungeranno mai).
Quando si sa che le prestazioni contano, chi le ricerca deve fare il
possibile per ottenere il massimo che può rispetto al suo livello di
conoscenza del linguaggio.
      Giuseppe

 memoria, di conseguenza la maggior lentezza.
Il loop è all'interno della dll. Ho provato a fare 100 chiamate (e
dividere quindi le iterazioni per 100), ma il risultato non cambia
sostanzialmente.
Probabilmente se facessi   1.400.000.000 non sarebbe così.
     Giuseppe

conoscenza del linguaggio.
Eh, vedi su. Hai voglia a cercare di infilare chiodi nel muro il più
efficientemente possibile. Se non hai muscoli a sufficienza, il
martello non lo alzi nemmeno ;-)

 martello non lo alzi nemmeno ;-)
Dopo aver esordito con una (giusta) puntualizzazione sulle qualità di
chi lavora nel settore dei gestionali che non ha niente da invidiare
agli altri, sembra che tutto quello che scrivi voglia dire "io sono
bravo, tu che non lo sei lascia perdere perche otterrai risultati
scarsi". Non lo dici mai espicitamente, però ci giri intorno.
Non vorrei deluderti, ma una buona parte delle cose che dovevo fare
(cioè elaborare e analizzare un flusso di immagini in tempo reale) le
ho già fatte in c# e vanno benissimo.
Questo mi dà la certezza che almeno un obiettivo minimo lo
raggiungerò. Sto solo cercando di ottenere risultati migliori.
Inoltre sto volutamente lavorando su un vecchio Amd Sempron. Se
funziona tutto su quel pc posso stare tranquillo.
E infatti sono abbastanza confidente.
Per alcune cose mi serve il c++. Ho fatto la prima capatina in questo
mondo: da qui l'apertura del thread.
La sintassi è molto simile, infatti il c# è nato ispirandosi al c++.
Sicuramente ci saranno molte differenze che emergeranno in seguito, ma
francamente sono ottimista (anche perchè mi sento "coperto" dalla
conoscenza del c#).
p.s.: rileggendo quello che ho scritto, spero che il tono non sia
interpretato come troppo polemico. la discussione sono sicuro che
rimarra civile e costruttiva.
ciao
     Giuseppe

 ho già fatte in c# e vanno benissimo.
"Non vorrei deluderti"?
Con tutto il rispetto: ma chi se ne frega? :-)
<salto tutto il resto>

 conoscenza del c#).
Ti suggerirei di non contare troppo su questo: usare C++ come "un C# un
po' diverso" è un  buon modo per usare male C++. C++ è un linguaggio
*notevolmente* complesso, come pura complessità forse il più complesso
che conosco (e attenzione che questo è sottilmente diverso dal
"difficile da usare").
In particolare la pragmatica di C++ è tipicamente diversa da quella di
C#. Per dire C è quasi un sottoinsieme di C++ (salvo alcune rilevanti
differenze semantiche). Di fatto tuttavia chi scrivesse C++ "pensando in
C" scriverebbe probabilmente pessimo C++.
C# è un linguaggio decisamente più semplice di C++. Per certi versi ha
meno alternative. Ha inoltre certi aspetti funzionali, specie nelle
versioni recenti. C++ pure permette uno stile abbastanza dichiarativo,
tuttavia lo fa in modo intrinsecamente diverso (molto più statico e meno
dinamico, e di fatto "di libreria" più che "di linguaggio"). 
-- 
-riko

 Prova le opzioni di compilazione -O, oppure -O2, oppure -O3.
IIRC usa pure una versione *parecchio* vecchia di gcc. O ricordo male?
-- 
-riko

 performance non lascia molta strada ad alternative al C++.
Andando OT, cose come Ada o Eiffel le avete scartate per motivi
"esterni" (costo/mancanza di ambienti di sviluppo e/o skill nel team) o
per altri motivi? [non è polemica, è solo curiosità]
-- 
-riko

 per altri motivi? [non è polemica, è solo curiosità]
Semplicemente perché nessuno ha mai preso seriamente in considerazione
quei linguaggi.
Ada era usato solo in un'azienda in cui sono passato, che lavorava in
ambiti militari.

 IIRC usa pure una versione *parecchio* vecchia di gcc. O ricordo male?
Dev C++ usa quello che ci metti sotto. Il compilatore è il mingw.

 Dev C++ usa quello che ci metti sotto. Il compilatore č il mingw.
Of course, ma IIRC le versioni pacchettizzate con Dev-C++ non sono le
piů aggiornate, anzi. Certo, le puoi aggiornare (a mano o forse in modo
automatico). Non so come si comporta con la beta di gcc 4, inoltre.
Io personalmente le rare volte che lavoro su Windows ho fatto la
transizione a Code::Blocks. Personalmente mi trovo molto meglio sotto
moltissimi punti di vista. Non ultimo il fatto che č abbastanza facile
fare progetti multipli per compilare sia con gcc sia con mvc++ sia con
altro ancora, il che č abbastanza comodo.
-- 
-riko

 quei linguaggi.
Ok.
-- 
-riko

 altro ancora, il che è abbastanza comodo.
Concordo. Quella che mi pare tristanzuola e' la condizione delle
distribuzioni di gcc per Windows: cygwin sta traghettando verso la
propria nuova versione da secoli, e nel frattempo e' fermo alla 3.4;
mingw si muove un pochino di piu', ma anche li' la versione ufficiale
e' sempre la 3.4.
Ciao,
Nicola

 distribuzioni di gcc per Windows:
Già.
Comunque anch'io uso Code::Blocks, avendo da tempo abbandonato DevC++,
anche per i suoi problemi di integrazione con gdb. Devo dire che
l'unica cosa che non mi piace moltissimo è che spesso si sia obbligati
ad eseguire un build, prima di lanciare l'applicazione. L'ambiente è a
volte incapace di avviare la compilazione, quando il sorgente è
cambiato, tra un lancio e l'altro.

 e' sempre la 3.4.
Mi chiedo se siano motivi politici o cosa. Non dovrebbe essere *così*
difficile.
-- 
-riko

difficile.
Credo che il problema sia la disponibilità di compilatori sotto
Windows e l'uso generale che viene fatto di gcc su questa piattaforma.
Sotto Windows esiste una miriade di compilatori e il gcc non è usato
tanto quanto compilatori un po' più radicati. Windows è praticamente
dominato da Visual C++; con gli ultimi Visual Studio, poi, una buona
fetta dello sviluppo è coperta da C#. La domanda di gcc, nettamente
inferiore rispetto a sistemi come Linux per esempio, limita anche
l'offerta.

On Aug 21, 7:48 pm, 
r...@despammed.com
 (Enrico Franchi) wrote:

Secondo me sono motivi economici. Dietro cygwin c'e' RedHat, che
evidentemente non ha interesse a spenderci piu' di tanto. Che io
sappia mingw non ha dietro nessuno e quindi il tutto e' lasciato alla
buona pace dei volontari disponibili, che evidentemente non sono
sufficienti.
Ciao,
Nicola

 On Thu, 21 Aug 2008 19:48:46 +0200, 
r...@despammed.com
 (Enrico

Tra l'altro con VC++ Express anche chi vuole fare le cose in modo
legittimo puo' dotare i propri sviluppatori di un ottimo strumento
senza spendere una lira e le uniche ragioni per puntare su gcc sono
eventualmente la portabilita', ma soprattutto la filosofia, che di
rado ha effetti benefici sui bilanci delle aziende.
Ciao,
Nicola

 rado ha effetti benefici sui bilanci delle aziende.
Un po` si stanno muovendo, e stanno saltando diverse tappe: (4.0, 4.1 e 
4.2...)
http://sourceforge.net/forum/forum.php?forum_id=820558
C'e' un altro vantaggio ad usare mingw, il compilatore e` disponibile 
anche su unix/linux e molte distribuzioni lo pacchettizzano (sia debian, 
che ubuntu che fedora che redhat x esempio).
Con pochissimi interventi manuali (giusto copiare i pacchetti di 
sviluppo delle librerie da usare x le applicazioni windows) e` possibile 
avere un efficiente crosscompiler, facilmente distribuibile tramite 
distcc su piu` server differenti.
A sviluppare su linux ci sono discreti vantaggi, in particolare per il 
debug post mortem o remoto dell'applicazione...
In azienda ormai sono 5/6 anni che usiamo mingw anche per applicazioni 
che solo internamente girano su linux, ma che in fase di deployment 
hanno come target windows (produciamo comunque sempre doppie versioni 
anche per dare al cliente la possibilita' di svincolarsi dai costi di 
licenza del sistema operativo).
Bye,
  Gabry

 licenza del sistema operativo).
Una domanda provocatoria: in questo periodo quanto avete investito in
termini di tempo e/o denaro sui progetti gcc e mingw?
Ciao,
Nicola

 tanto quanto compilatori un po' più radicati. 
Non saprei. Mi spiego: MS la fa sicuramente da padrona. Intel ha una
nicchia (che però è una nicchia, visti i costi di licenza). Watcom è
sostanzialmente in stallo. Rimane Borland (o come si chiama ora), ma
IMHO non è più diffusa come qualche tempo fa. Complessivamente credo che
gcc si sia allargato (anche se molto poco diffuso rispetto a MS).
-- 
-riko

 sufficienti.
Quindi direi "politici": in se e per se credo che i soldi per fare il
porting su windows di uno dei più diffusi (e apprezzati) sw open source
ci potrebbero essere. Il punto è che FSF non *vuole* investire in tal
senso (ne incentivare gli "hobbisti" a lavorarci). 
Mi ricorda la posizione dello sviluppatore di FrozenBubble, scritto in
modo da essere *molto* portabile che scoraggiava esplicitamente i port
per Windows per non incentivare in nessun modo la piattaforma (eh, chi
non passa a Linux solo per giocare a FB... :P).
-- 
-riko

Non saprei.
Te lo sto dicendo, non te lo sto chiedendo :-)
Fidati: Visual C++ è sicuramente il dominatore, per quel che riguarda
lo sviluppo in C++, sotto Windows. Il gcc rimane di gran lunga meno
utilizzato.

 utilizzato.
E su questo sono d'accordo, grazie tante! :P
Il fatto è che "fra gli altri" non sono molto convinto che il gcc sia
poco utilizzato. 
-- 
-riko

 utilizzato.
E su questo sono d'accordo! :P


Enrico Franchi ha scritto:

Vero, sotto Windows VisualC++ stradomina, pero' come utilizzo globale
sicuramente gcc batte di gran lunga Visual studio per il semplice
motivo che e' portato su una infinita' di piattaforme e micro(1)(2),
dagli AVR a 8bit(solo C) agli ARM, ai PPC, RISC etc... se ci si
astrae un poco dal mondo PC, che globalmente rappresenta solo una 
piccola percentuale relativamente alla parte di sviluppo C/C++,
si vede che il gcc e' di gran lunga il compiler piu' utilizzato
(anche se forse e' meno figo sviluppare applicazioni per distributori
  automatico di bevande ;-)
Bye
B.
(1) Oddio, anche il VisualC++ ha qualche porting su
     architetture varie (per CE), ma non cosi' diffuso
     come il gcc perche' orientato appunto a CE.
(2) vedi EDN, classifica annuale dei uC piu' diffusi e relativi
     tools (di solito il numero di Gennaio, se non vado errato).