Newsgroup: it.comp.lang.c
Titolo: il C++ è terribilmente più lento del C?

è quello che affermano in molti, partendo dal concetto che comunque più alto
è il livello di un linguaggio di programmazione meno può essere ottimizzato
il codice etc. etc.
alcune persone dànno la colpa all'OOP per le mostruose richieste in termini
di risorse dei programmi commerciali d'oggi, piuttosto che alla oggettiva
complessità di questi ultimi.
la mia domanda è: fino a quanto questi discorsi sono veri?
PS scusate il crosspost ma visto l'oggetto sembra opportuno.

 la mia domanda è: fino a quanto questi discorsi sono veri?
Il C++ non è per nulla più lento del C !
Tanto e' vero che se programmi modalità C-style e' (dipende dai compilatori)
un tantino piu' veloce (in sotanza il contrario di quello che dici).
Riguardo alla OOP, se usata con giudizio, non rallenta quasi nulla le
applicazioni. Se invece si diventa class-happy e si usa il C++ in modo non
opportuno le prestazioni possono calare ;-)
Tieni a mente che ogni singola caratteristica che e' stata aggiunta al C++
e' stata pensata ed implementata in modo da non danneggiare le prestazioni.
Riguardo alla lentezza dei programmi di oggi....
Ti smentisco subito dicendo che i programmi di oggi sono effettivamente
complicati !!!
Poi e' vero che alcuni usano troppa memoria etc... ma questo e' un altro
discorso.
Per concludere, alcuni programmi di oggi, senza l'ausilio della OOP
sarebbero molto piu' difficili e richiederebbero molto piu' tempo per essere
implementati. Inoltre grazie alla OOP e' piu' semplice lavorare in grossi
team di sviluppatori.
Ma dimmi, con questa domanda, a che cosa volevi giungere ?!?
Dovremmo forse tutti programmare in assembly ? ;-) (scherzo)
Alex

 Dovremmo forse tutti programmare in assembly ? ;-) (scherzo)
sono solo incuriosito sulle differenze tra i due linguaggi.    :)    spero
non siano curiosità importune per il NG
grazie per i lumi    :-)

 grazie per i lumi    :-)
Figurati!
Alex

 che tu lo conosca davvero bene!
ok, il bello del C++ probabilmente è che puoi spaziare da un livello
veramente vicino all'hardware fino al livelli di astrazione che non hanno
pari in altri linguaggi... ma io non ho ambizioni masochiste, voglio
imparare solo un pò di C!    :)

 imparare solo un pò di C!    :)
Su questo non sono concorde!
Potresti iniziare il C++ con la parte C-style.
Poi appena ti senti sicuro passare alla parte OO.
Dipende da cosa ti piacerebbe fare in un futuro, per alcune cose non vale la
pena di imparare il C++ per altre si. Ma ripeto anche nel primo caso
potresti imparare la parte Cstyle del C++!
Alex

 potresti imparare la parte Cstyle del C++!
su it.comp.lang.c++ N. Musatti che ha risposto a questo stesso
msg. con considerazioni molto simili alle Tue, a riprova della
bontà dei consigli di entrambi; in particolare anche Lui mi
consiglia di partire con la parte C-like di C++; a farlo ho un
solo dubbio, e ti riporto i dubbi che ho manifestato a Lui:
"è quello che pensavo anch'io, [a proposito del partire con il
C++] poi ho visto un libro sul C e un
paio sul C++ (li ho giusto scorsi) e l'approccio era
completamente diverso: nei libri sul C++ si trattava ogni
problema in termini di classi, non uno struct, non una semplice
funzione, sarà che ho consultato libri sbagliati?
ho notato che c'è molta ammirazione per il lippmann della
addison, che per essere un libro da 1200 pp. ha anche un costo
molto contenuto, continuo a chiedermi se studiando con calma da
un libro dedicato al C++ si possa arrivare a capire bene cosa
avviene a "basso livello" o anche a usare con cognizione di
causa il preprocessore o roba del genere, cose che su un buon
libro C sono per lo meno menzionate (scusa se dico fesserie ma
sono veramente nuovo del C), puoi darmi qualche consiglio?; io
ho fatto solo un pò di programmazione procedurale in VBA, ho
anche messo sù un paio di "oggetti" (il VBA/VB ha una
rudimentale gestione degli oggetti senza ereditarietà&company)."
grazie.

 rudimentale gestione degli oggetti senza ereditarietà&company)."
Beh, una idea di cosa sia programmare almeno te la sei fatta !
Alex

eseguibile piů veloce?
Non e' del tutto esatto...
La situazione attuale e' che le compagnie che sviluppano sw hanno
abbandonato i compilatori C, o meglio ne hanno abbandonato lo
sviluppo, concentrandosi su compilatori bivalenti, cioe' che masticano
sia C che C++.
Se compili lo stesso file (.C) con lo stesso compilatore non otterrai
alcun miglioramento forzando la compilazione in C++.
ciao, acc.   
a...@libero.it

 Beh, una idea di cosa sia programmare almeno te la sei fatta !
Penso di essermi fatto le ossa a sufficenza, in effetti ho
dovuto anche fare i salti mortali: ho lavorato un paio di mesi
in una azienda che si occupava di GED (ci sono capitato in modo
rocambolesco), pur non essendo un programmatore mi è toccato
mettere sù un DB da 80K records (ahimé con Access, ti lascio
immaginare...) con i committenti che ti cambiavano idea 2 volte
al giorno... ho anche dovuto imparare SQL a tempo di record,
visto che le richieste dei committenti erano così particolari
che mi è toccato scrivere a mano (ho scoperto poi essere il
metodo più comodo) query piuttosto complesse.
Era iniziato come un gioco, un paio di maschere di immissione
dati, alla fine ho dovuto strutturare una vera è propria
applicazione ben divisa in procedure con l'aggiunta di alcuni
oggetti.
cmq, tornando a bomba mi sembra chiaro il concetto: imparare i
rudimenti del C su un libro qualsiasi (ad esempio mi hanno
prestato il libro di un certo Gottfried che personalmente
ritengo prolisso e mal strutturato nell'ordine degli argomenti,
ma è gratis!) e poi il Lippmann che manca solo delle soluzioni
degli esercizi.
grazie per le dritte.

 generalizzazione delle strutture
Si, rispetto alle struct C. Le struct in C++ sono cambiate, sono
praticamente come le classi C++. La differenza?!? Le struct hanno di default
tutti i membri pubblici e le classi private.
Alex

 alcun miglioramento forzando la compilazione in C++.
Beh, non sono totalmente concorde!
Ad esempio il C++ essendo piu' rigido in molte situazioni forza una
scrittura del codice piu' pulita. I #define che posso essere tranquillamente
sostiutiti sono un gran vantaggio (visto che sono insicuri).
etc...
Alex

sostiutiti sono un gran vantaggio (visto che sono insicuri).
Problema facilmente aggirabile, BTW trattandosi di direttive del
preprocessore, anche queste non c'entrano niente con le prestazioni
velocistiche.
ciao, acc.   
a...@libero.it

 velocistiche.
Infatti qualche giorno fa ho scritto:
<QUOTE>
Beh, puo' essere, ma piu' che altro il codice, su un compilatore C++, viene
controllato piu' rigidamente e quindi hai meno possibilita' di fare errori
difficilmente trovabili.
Moltissimi programmatori C oggi compilano il loro codice con compilatori C++
per ottenere risultati migliori.
</QUOTE>
Io infatti non mi riferivo alla velocita' !
Io rispondevo alla tua affermazione:
"Se compili lo stesso file (.C) con lo stesso compilatore non otterrai
alcun miglioramento forzando la compilazione in C++."
Beh, miglioramento non sottointente di velocita' !
Ad ogni modo sembra non ci siamo capiti :-)
Alex

scusa se m'intrometto    :)    che vuol dire "I #define che
posso essere tranquillamente sostiutiti sono un gran vantaggio
(visto che sono insicuri)."
"Alex" <nom...@bow.wow> ha scritto nel messaggio
news:yPWg7.2729$i81.1...@news.infostrada.it...


"Alex" <nom...@bow.wow> ha scritto nel messaggio
news:%MWg7.2711$i81.1...@news.infostrada.it...

grazie per la spiegazione, vado a vedermi le struct...    :)

(visto che sono insicuri)."
Credo si riferisca al caso di una definizione di macro dove i
parametri della stessa siano referenziati piu' volte.
Un richiamo di questo tipo di macro con espressioni come parametro
puo' essere insicuro...ma basta saperlo !
ciao, acc.   
a...@libero.it

 ciao, acc.   
a...@libero.it