Newsgroup: it.comp.lang.c++
Titolo: velocità in C++

 
Permettimi di dissentire.
Se parliamo di compilatore 'grezzo' allora il C++ e' effettivamente un 
compilatore che quel che deve fare lo fa velocemente.
Il tuo esempio credo sia sbagliato in partenza, ci sono una serie di 
programmi e di tecniche di programmazione che *ovviamente* costano 
velocità che prescinde dal compilatore.
Inoltre, problema di fondo, non mi pare che la programmazione ad oggetti 
favorisca la velocità o l'ottimizzazione dell'uso della memoria, ma 
esattamente il contrario ( ovviamente e io uso strumenti messi a 
disposizione dal compilatore come controllo accessi etc. etc. etc.) 
*ovviamente* saranno necessarie maggiori risorse.
E' il punto di vista che è completamente diverso rispetto al paradigma 
imperativo, e la programmazione oo si sviluppa tutto in quel contesto.
E' un discorso che se messo in questi termini finisce per 'puzzare' di 
flame...

 (aggiungo che io non so niente del Java)?
Veramente è il contrario.
Di norma più il codice è voluminoso, più è veloce
l'esecuzione dello stesso. Questo perchè avendo a
disposizione molto spazio per il codice si possono
mettere istruzioni per trattare direttamente tutta
una serie di casi particolari per cui invece, con
un codice di dimensioni ridotte, bisogna fare un
sacco di test, loop e verifiche per trattarli con
il poco codice disponibile.
L'equazione "programma grande = programma lento"
è sbagliata... in generale non è così.
Non a caso con i compilatori di qualche anno fa
dovevi scegliere se ottimizzare per la velocità
o per la dimensione del programma, cioè se averlo
piccolo e lento o grande e veloce.
Chiaro che poi, se uno programma ad alto livello,
usando strati e strati di librerie, con un linguaggio
poco efficiente e usa algoritmi non appropriati
ottiene un programmone di 10MB che va come una lumaca...
per fare programmi decenti bisogna saper programmare
almeno un pò. Peccato che, a quanto pare, quest'arte
ormai la coltivino in pochi :-)

 imperativo, e la programmazione oo si sviluppa tutto in quel contesto.
Il C++ è anche lui un linguaggio imperativo...
l'OO non è sinonimo di non-imperatività

 codice da scrivere?
tanto
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.5. C, C++ and ASM developers
                               and beta testers are welcome!

 migliore del programma.
Evitando di parlare di C++ e C, ma parlando di C++ utilizzando OO e C++
senza utilizzare OO....
Non vedo come un programma che utilizza OO possa essere piu' veloce di uno
che non la usa, al limite puo' essere veloce uguale!
Se poi stai dicendo che un design ed una struttura migliore spesso portano a
prestazioni migliori, beh, questo non ha nulla a che fare con la OO in
particolare.
Tommy


Rieccomi .
Sono appena tornato. :)
Allora, premesso che per me l'*unica* scelta valida e' quella dettata 
dalla passione (se non ho particolari richieste io sceglierò SEMPRE il 
linguaggio che mi piace), c'è effettivamente da fare una distinzione: 
concordo con chi dice che l'utilizzo di C++ non è sinonimo di OOP. 
Verissimo. Lo davo per scontato *in questa discussione*.
E' altrettanto *ovvio* che se devo fare un programma (GENERICAMENTE 
parlando) posso farlo in una maniera tale che lo rendo lento anche in 
assembler.
Il problema qui e' che credo si debba restringere il dominio.
Parliamo di OOP pura ? Benissimo, il c++ e' effettivamente MOLTO più 
veloce di java. Il problema è che *secondo me* qualunque linguaggio 
abbia bisogno di una VM come quella di JAVA ha da pagare in termini di 
velocità.
NON CI SONO SANTI. Velocità vuol dire vicinanza alla macchina. 
Ovviamente java avrà le sue ragioni e le sue chicche, ma nasce per 
essere potrabile e finquando non esce qualche cristiano al pari di 
Turing che dimostra il contrario sarà sempre più lento, perchè 
rieseguibile su più macchine (e la mia esperienza di *spettatore* di 
team di sviluppo in java potrebbe smentire - almeno in alcuni contesti - 
questa tesi).
Il dominio della discussione non deve inoltre neanche tener conto di 
problematiche esterne al linguaggio come il multithreading, inquanto 
appunto esterne.
Poi - per puro gusto di polemica - riprendo un messaggio postato nn 
ricordo su quale ng circa la questione java.
Fa un programmino che esegure "ls ." in C++. Occuperà i suoi kb più il 
supporto a runtime.
Fallo in java e carica tutta la VM (ed i suoi MB).
Ciao.

 questa tesi).
Intendevo dire 'confermare'....avevo appena litiga con le bottiglie di 
vino su scusatemi !!

 C++?
La risposta è: prova a scrivere un programma "pesante" (a livello di
algoritmo/calcolo) in C++ e in Java (usa tutti gli oggetti che vuoi, a patto
che i programmi siano comunque comunque corrispondenti) e falli girare sullo
stesso calcolatore, poi, dopo, dicci cosa vedi !

 rapporto alla quantità di codice da scrivere?
Io penso che è un discoroso per il quale non sei ancora pronto. Quando si
lavora a un progetto, si scelgono gli strumenti sulla base di tanti
elementi. Java e C/C++ non sono in concorrenza. Chi sceglie Java a
determinate esigenze, chi programma in C ne ha altre.
A volte la scelta di scrivere in C++ o in Java risponde ad esigenze
sovrapponibili (OO Software Engineering), ma in generale, questo è
indifferente solo quando non si è vincolati ad esempio (perché i motivi sono
tantissimi) a problemi prestazionali (velocità) oppure quando il programma
deve integrarsi con altre tecnologie (es Java e WWW). I due linguaggi hanno
una natura totalmente differente... La tua domanda non ha alcun senso.

 wrote:
Scusa ti spiacerebbe quotare in modo piu umano ?

 
Volevo quotare solo la frase 'incriminata' ma ho cancellato una riga in più.
Errore mio ma con un piccolo sforzo potevi anche capirlo.

 tanto
Tra parentesi a livello di linguaggio base, soprattutto grazie ai
template, in C++ si scrive molto meno codice che in Java per fare le
stesse cose. Per contro e' vero che Java ha una libreria standard
molto piu' estesa (nel bene e nel male).
Ciao,
Nicola

 questa tesi).
...attenzione pero' che e' sempre possibile che la qualita' relativa
di due implementazioni (ad esempio ottima in Java e pessima in C++)
possa in termini concreti ribaltare la situazione. Java si tira dietro
da sempre la fama di esser lento e la Sun ha investito un grosso
sforzo nel dimostrare il contrario; i produttori di compilatori C++
sono troppo occupati ad implementare i dettagli piu' oscuri dello
standard per potersi lanciare anima e corpo sull'ottimizzazione.
Ciao,
Nicola

 stesse cose. 
Sottoscrivo, ma mentre leggevo sorridevo pensando a come un sostenitore 
qualunque di java come linguaggio superiore (*ribadisco* che per me non 
sono commensurabili i 2 linguaggi) sarebbe disposto a fare fuoco e 
fiamme per dimostrare il contrario.
Uno dei cavalli di battaglia dei 'java stalkers' (oddio che definizione) 
  è che un programma nel loro linguaggio preferito si scrive 'veloce 
veloce' senza scervellarsi districandosi nell'oscurità del C++.
Sinceramente non ho mai replicato ad una cosa del genere. Non avevo 
tempo e voglia.
( E pensavo anche a quanto detto da qualche parte in questo ng della 
standard proposal di alcune librerie di Boost ).
j0k3r

Volevo quotare solo la frase 'incriminata' ma ho cancellato una riga in più.
Mi riferivo ,evidentemente, al post del 14/12/2003  h 01:20 .


Guarda che ho semplicemente quotato il messaggio per intero. E secondo 
le direttive di Messenger.