Newsgroup: it.comp.lang.c
Titolo: C e C++

Scusate la domanda,
Sempre più spesso si sentono frasi come il C è un sottoinsieme del C++, il C
è morto, ecc... . Allora mi viene da pensare che sono stato un vero cretino
ad imparare il C e successivamente le fondamenta del C++ quando potevo fare
il salto diretto. Se come dice Stroustrup il C viene solo mantenuto per
questioni di compatibilità, allora mi date l'autoconvalida che quanto
espresso sopra è vero.
Sperò che questa frase sia stato un errore di traduzione.
Che C sia un sottoinsieme di C++ d'accordo, ma che Stroustrup lo consideri
come morto...
Ciao e buona domenica  (sera).


wrote:

Puoi invece affermare tranquillamente il contrario, il C++ e'
un'estensione del C.  Le prime implementazioni di C++ erano infatti
realizzate solo a livello di preprocessore, quindi utilizzando un
normale compilatore C.
Cio' che afferma Bjarne Stroustrup non e' vero, parecchi progetti
vengono realizzati in C.
La quasi totalita' dei kernel dei sistemi operativi, questo perche' i
programmatori che li sviluppano si rifiutano di farlo col C++, il
motivo c'e', ma non voglio scatenare un flame...
ciao, acc.   
a...@libero.it

"acc" <a...@libero.ita> ha scritto nel messaggio
news:92q6et4en906uk85a...@4ax.com...

Potresti farlo visto che nel NG del C++, mi hanno praticamente lapidato per
aver detto che un progetto di S.O. in C è + efficiente di uno in C++ in
termini di velocità!!! Spero di non sbagliarmi!

 il salto diretto.
Diciamo che se devi imparare una certa filosofia di programmazione,
magari "invasiva" coma la OO (nel senso che ti costringe a modificare
tutti i tuoi punti di vista sulla progettazione del software), sarebbe
meglio cominciare direttamente con essa.
EMG

 un'estensione del C.
Questo punto di vista è, secondo me, assolutamente fuorviante. In realtà
vedere il C++ come semplice estensione del C è, si, uno dei suoi
possibili usi ma che ne esclude, diciamo, il 90% delle potenzialità.
EMG

francesco....@libero.it
 wrote:
il buon Alex Martelli ti risponderebbe (e chiunque altro dotato di buon 
senso ;-)) che un linguaggio di programmazione ha delle peculiarità per cui 
risulta adatto per alcuni tipi di progetti e totalmente inadatto per altri. 
Un esempio potrebbe essere la gestione delle stringhe: prova a fare 
qualcosa che non sia semplicemente banale in C e poi falla in Perl. In 
questo caso vince il perl 10 a 0, sempre che tu non cerchi delle 
particolari prestazioni...
A ripensarci il buon Alex Martelli non si sarebbe mai impelagato in un 
argomento così impegnativo con un intervento così leggero... ^______^
Simone

 uno in C++ in termini di velocità!!! Spero di non sbagliarmi!
Dipende da cosa hai detto e come, penso...

termini di velocità!!! Spero di non sbagliarmi!
Affermare che un programma in C sia piu' efficiente di uno in C++ non
e' del tutto corretto, in fondo, semplificando possiamo dire che dato
che il C++ comprende anche il C, allora col C++ posso scrivere un
programma equivalente al C (basta togliere tutti i ++ )  :-)
Scherzi a parte... Il C++ come ogni linguaggio ha i suoi pregi e
difetti. Parlando dei difetti, rispetto al C, e' piu' difficile
scrivere codice efficiente, e si badi bene, ho detto difficile non
certo impossibile.  In pratica per ottenere prestazioni elevate in C++
e' richiesta una certa esperienza, ma il fatto che ad esempio molti
giochi siano scritti in C++ la dice lunga in fatto di prestazioni di
questo linguaggio.
E' difficile fare confronti tra i due linguaggi, teoricamente il C
puo' fare tutto quello che fa il C++, e viceversa, ma se guardiamo
alla realta' troviamo che il C++ si adatta meglio in certi ambiti, un
kernel lo farei in C, ma una GUI.........anche!
Bhe' cosa pretendevate ?  Io programmo in C, e non ho mai sentito il
bisogno di passare al C++, dovrei forse fargli un monumento ?
ciao, acc.   
a...@libero.it

"acc" <a...@libero.ita> ha scritto nel messaggio
news:9re9etoqv1dokqr4l...@4ax.com...

Pure io programmo in C e ormai da diversi anni ... ho affermato che il C è +
efficiente del C++ riferendomi alle possibilità di ottimizzarne il codice
... ma un attimo: ok, il C++ contiene tutto il C, ma secondo me sarebbe
leggermente sbagliato programmare in C misto al C++, cioè non ci vedo quasta
gran logica ... secondo me non è corretto perché usare un misto ... cioè ...
viene fuori una porcheria di programmazione no? Sinceramente io vedo la
necessità di separare le due cose ... da una parte una metodologia ad
oggetti e dall'altra una cosa che si avvicina molto la macchina.
Sinceramente molti giochi nel passato erano programmati solo in C puro con
ottimizzazioni estreme e con tanto ASM di mezzo per recuperare qualche ciclo
della macchina. Ultimamente vengono scritte in C++, ma per motivi ben
diversi dalle ottimizzazioni, in quanto l'ottimizzazione del codice C++ è
ben complesso!! GLi sviluppatori lo usano, ultimamente, non per questo
motivo, anche perché non lo ottimizzano affatto ... ma perché risultà molto
+ semplice scrivere il codice e gestire alcuni oggetti ... non ché
l'implementazione delle strutture astratte come le liste e gli alberi BSP.
Io ne so qualcosa, visto che ultimamente mi sono messo in testa di fare un
videogioco 3D ... alcuni autori mi consigliano il C, per il codice
estremamente veloce, altri il C++ per la facilità di gestione ed
implementazione!! Purtroppo nella grafica recuperare anche 1 solo ciclo di
clock della macchina è vitale!!

argomento cosě impegnativo con un intervento cosě leggero... ^______^
;)
Avrebbe sicuramente risposto con qualche esempio in Python, Smalltalk,
Eiffel, e chi + ne ha + ne metta ;)
p.s.: parenti ??

possibili usi ma che ne esclude, diciamo, il 90% delle potenzialità.
Ovviamente sono d'accordo.

 clock della macchina č vitale!!
Una volta. Ora, con i processori grafici che fanno tutto la cosa non č
piů cosě critica e i risultati sono di gran lunga migliori (confronta,
ad esempio, i giochi basati sull'OpenGL con quelli puramente software).
EMG
PS. Siamo OT.

clock della macchina è vitale!!
Il C++ e' veloce tanto quanto il C (a volte anche di +).

 Il C++ e' veloce tanto quanto il C (a volte anche di +).
Boh ... io ho provato a fare una semplice stupidaggine di una palina che
rimbalza da un lato all'altro dello schermo su di un PIII 700 e mi è
risultato + lento dello stesso codice in C, anche con le ottimizzazioni
estreme insegnatemi dall'autore del tutorial ... tutto dipende se il
programma in C è scritto bene .... ribadisco che secondo me niente è +
veloce di un programma che usa meno istruzioni e quelle che ha sono con
pochi cicli di  clock ... cmq se il programma in C++ è migliore in questo
ambito certo che è + veloce, ma allo stesso modo lo è quello del C, basta
solo starci attenti e fare le cose per bene!!


Ciao a tutti
e scusate se mi intrometto... ovvio lo faccio solo per uno scambio di parei
poi è ovvio che ognuno può rimanere della propria idea anche in base alle
esperienze che ha avuto...
Io vorrei solo precisare qualcosa sull'ottimizzazione....
Ottimizzazione è una parola un po' grossa al giorno d'oggi... io direi che
quasi
nessuno può scrivere codice ottimizzato... Io ci ho provato e ho anche
analizzato
i risultati con VTune, un tool dell'Intel...
Il risultato è il seguente... dal PII in poi ogni processore è un CISC con
nucleo RISC
con funzionalità di speculative execution, multiple branch prediction,
ecc...
Inoltre la stessa struttura interna del processore non è quella visibile al
programmatore/programma,
invece dei registri classici EAX, EBX, ..... ECS, EDS, ..... vi sono 128
registri mappati con alias
sui registri standard, pipeline multiple, ecc ecc..
Dopo che il programma è stato scritto in ASM, ecco quindi che viene
scomposto in micro-OP (così
le chiama Intel) le quali vengono riorganizzate, spostate ecc ecc in
funzione degli algoritmi interni
che cercano di prevedere il flusso del codice e mantenere piene tutte le
pipeline contemporaneamente
(cosa ovviamente impossibile in modo deterministico).
Il risultato è che scrivere un codice ottimizzato persino in ASM è di una
complessità mostruosa
e nessuno investirebbe tempo e soldi per ottimizzare il codice su macchine
che tanto tra 1 anno
sono obsolete e soprattutto con un sistema come Windows alle spalle che non
è ottimizzato, e ancora
con frequenze di clock, memorie di massa e non che non pongono limiti
specifici.
L'unica vera ottimizzazione che viene fatta, in contrapposizione a quello
che dici tu, è proprio
nei videogiochi (ma non in tutti, dipende dalla bravura/TEMPO dei
programmatori).
Però l'ottimizzazione non è globale, ma critical-oriented, ad esempio negli
engine grafici
o nell'utilizzo di feature specifiche (programmazione dei Vertex Buffer....
ecc..)
Altra cosa è invece l'ottimizzazione grossolana di un codice... ad esempio
posso decidere
di utilizzare variabili a int a 32 bit per sfruttare il parallelismo
dell'hardware, oppure
eliminare sequenze interminabili di switch/case con vettori di puntatori a
funzione,
o scegliere bene le strutture dati... e molto altro. Questo si può e si deve
fare....
Ciao a tutti
ByZ-2K

Andrea Laforgia wrote:

Solo un caso di omonomia.
Ma č un mito per chi naviga tra questi argomenti da qualche anno...
Simone

clock della macchina è vitale!!
Forse mi hai frainteso, non intendevo 'mescolare i due linguaggi',
insomma o usi uno o l'altro.  O meglio ancora, a seconda di cio' che
devi sviluppare scegli quello che ritieni piu' adatto allo scopo.
Come dice Ron Dennis:
scegli gli strumenti giusti...usali bene... ;-)
Il C++ permette astrazioni molto spinte, che per certi scopi sono
sconsigliabili, ad ogni modo nessuno ti obbliga ad utilizzarle.
Non definirei questo 'usare il C++ in maniera limitata', certi
programmi vanno fatti secondo criteri particolari, del resto se punti
al massimo dell'efficienza, sai bene che cio' condizionera' il tuo
modo di programmare indipendentemente dal linguaggio che usi.
Un bubble-sort in assebler puo' essere piu' lento di un quick sort in
basic interpretato.
ciao, acc.   
a...@libero.it

viene fuori una porcheria di programmazione no? Sinceramente io vedo la
ma perchè la gente continua ostinatamente a dire C++ == OOP ????
Il C++ non è un linguaggio solamente OO. Il C++ è un linguaggio
multiparadigma: ovvero, offre un certo supporto a diversi paradigmi di
programmazione (strutturato, OOP, program generica ecc.). Punto.
Quindi se uno scrive in C++ si può servire del paradigma che reputa
migliore per il particolare progetto che sta sviluppando. Se la
programmazione strutturata è preferibile in un cero contesto, non vedo
perchè non usarla; esistono altre decine di miglioramenti che il C++
offre rispetto al C, anche se non si programma OO.
Anto
--
Antonio Cuni, 18 anni, studente
Brainbench Certification: 
Master C++: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
http://www.brainbench.com/transcript.jsp?pid=1301688

Ovviamente sono d'accordo.
ovviamente sono d'accordo anche io ;-)


La prima è praticamente vera. La seconda assolutamente no.
E il C non ha ragione di esserlo, almeno al momento attuale: infatti
il C++ ha almeno 3 grossi difetti rispetto al C:
1) non esiste un compilatore 100% standard
2) di conseguenza la portabilità ne risente, e parecchio
3) i compilatori odierni non sono abbastanza sofisticati per
ottimizzare nel miglior modo possibile; quindi è realisticamente
possibile che codice C risulti più veloce rispetto a codice C++
Notate che, cmq, sono tutti difetti imputabili al compilatore, non al
linguaggio in se; secondo me, a parità di compilatori, non avrebbe
senso usare C invece di C++
Anto


 possibile che codice C risulti più veloce rispetto a codice C++
Non stai considerando quella che dovrebbe essere la migliore arma C++ 
rispetto al C: ovvero la possibilita' di scrivere un algloritmo migliore in 
virtu' della sua maggiore potenza espressiva....
Si e' vero che tutto cio' che si puo' fare in C++ lo si puo' fare in C e 
viceversa; ma nell'uso quotidiano a volte la maggiore "semplicita" del C ci 
costringe a scrivere piu' codice offuscando la nostra capacita' di astrarre 
e di migliorare il codice stesso.
I template, le classi "dovrebbero" consentire di scrivere meno codice ed 
avere tempo di pensarlo meglio.

 
http://www.brainbench.com/transcript.jsp?pid=1301688
Con un linguaggo OO uno si aspetta di programmare in OO, certo che č ovvio
che non me lo vieta nessuno ... ad esempio un'implementazione personale
delle liste, mi impone di definire la procedure di destroy in ricorsione e
tante altre funzioni in programmazione strutturata, ma  ... dico io ... se
il C++ ci offre le iostream, perché utilizzare ancora le fopen &Co.?
Questo č quel che intendo io ... tutto qui! Se volessimo esser cattivi, un
programma in assemberl puň essere considerato un programma C++ visto che il
C++ mette a disposizione anche quello ... ma mi pare un po' declassante no?
Quella sarebbe solo programmazione Asm e non C++!

"Goffredo Baroncelli" <krei...@earthling.net.antispam> ha scritto nel
messaggio news:vg17c9...@therra.bhome...

Diciamo che ci sono alcuni progetti che vengono fuori in modo +
comprensibile in C ed altri in C++. Certo che un progetto di grafica
semplice riesce meglio in C perché si può analizzare concretamente quel che
si sta facendo e tutti i pasaggi che fa il programma, mentre se si richiede
di un programma con una pseudo programmazione ad eventi, mi risulta +
semplice farlo in C++, o meglio in OOP.
Purtroppo la cosa continua a restar divisa per il fatto che ci sono 2
mentalità diverse nella programmazione:
1) chi continua con il vecchio metodo
2) chi continua con quello nuovo.
Giusto ieri ho scaricato la libreria Allegro del Djgpp per la grafica, e ho
visto che il codice è interamente scritto in C e non in C++. Secondo me, la
ragione sta nel fatto che con il C, nonstante il casino che potrebbe venir
fuori, il programmatore si rende effettivamente conto di tutti i passaggi
che il suo programma sta facendo, ne + ne meno. Sinceramente è + visibile la
chiamata a "distruttori" in C che tutto l'arcano che sta dietro ad una serie
di oggetti virtuali del C++. Con il C si è sempre a conoscenza di quale sia,
mentre nel C++, se la cosa è un po' troppo strutturata gerarchicamente, alla
fin fine ci si perde la testa.
Ma, prendiamo in conto un a cosa:
int operator + (object a, object b) {
 ...
}
questo è un codice C++ no? Ma poterbbe essere anche C (se si tralascia la
sintassi) ... in fin dei conti è tale e quale a una funzione della
programmazione strutturata, solo che cambia il nome. Ovvio, se object non è
derivata e per tipi diversi c'é operatori ridefiniti....
Ma cmq, aggiungendo un parametro ai metodi C++, si ottiene codice
"Strutturato" e con qualche particolare in + si potrebbe riscrivere il
codice in C perfettamente funzionante.
In riassunto, un programmatore usa la programmazione strutturata quando ha
l'esigenza di controllare passo x passo cosa sta effettivamente facendo,
senza doversi scervellare a cercare quale maledetto costruttore o
distruttore o metodo virtuale viene richiamato ad ogni passo. Insomma, la
OOP avvantaggia in fase di sviluppo, ma rende la vita difficile in fase di
debug.
Concordate con quanto detto?

 ha scritto nel messaggio
news:W5hF6.3515$4u1....@news1.tin.it...

Si pergettamente d'accordo che un codice non può essere ottimizzato al
massimo, e questo sinceramente lo lascio fare al compilatore, ma ho visto
che ci sono alcune "stranezze" che mi permettono di realizzare la cosa in
modo + veloce.
Ad esempio:
unsigned char *vga = (unsigned char *)0xA000;
vga[x + y * 230]  = color;
quest'ultima istruzione, è lenta perché la moltiplicazione impiega
abbastanza tempo. Tutti insegnano che per fare questo calcolo y * 320
equivale a:
(y << 8) + (y << 6)
che è molto + veloce. Per cui:
vga[x + (y << 8) + (y << 6)]  = color;
é + veloce della precente. Il fatto sta che ad un certo punto si ha la
necessità di spostare il contenuto di un buffer nella memoria video. E un
buffer di
320 x 200 = 64000
in un ciclo del tipo
while( ... ) {
  cancella_vga(0);
  ...
  copia_to_vga(buffer);
  ...
}
dove il cancella non fa altro che un copia_to_vga con un solo byte a nero
.., ci troviamo a copiare 128000 byte ad ogni ciclo, senza contare tutte le
altre operazioni che stanno in mezzo ... per cui la cosa se non ottimizzata
nemmeno un pochino, fa veramente schifo e io l'ho provato!!
Poi tutto il resto, eheheh, viene lasciato a speciali ottimizzatori della
casa produttrice del processore...

 della casa produttrice del processore...
e gia'.
ma scusa, tu lavori in 320x200? hai mai provato un bel buffering 
sfruttando la memoria video e lo switch del puntatore inizio pagina? 

 ha scritto nel messaggio
news:2115442.A...@tin.it...

Certo! Ma quel l'esempio era il + semplice che mi veniva in mente!!!  Certo
che poi nessuno sviluppa un gioco in 300x200 quando c'è lo standard VBE che
mi permette di utilizzare tutte le risoluzioni video! Ma anche li ci sono
ottimizzazioni sulla copia. In ASM lo fai con 2 righe di codice ... se usi
il C, l'ASM generato è molto + lungo!!

 ha scritto nel messaggio
news:2115442.A...@tin.it...

Mi ero dimenticato....pardon: Cmq il copy_to_vga ....che poi sarà una copia
su vbe nell'altro caso, serve a copiare uno sprite letto da qualche altra
parte ... per cui quell'operazione la si deve fare lo stesso ... il che
equivale che sostanzialmente lo sviluppo del programma non cambia di molto!!
Che intendevi dire di preciso?

 Che intendevi dire di preciso?
si puo' dire alla scheda da che punto della memoria inizia la parte 
da inviare a schermo: senza copiare nulla, hai il double buffering 
spostando questo indice avanti e indietro. 
es.
memoria video
[schermata_a] ... [schermata_b]
A e' pronta per l'invio a video, e imposto l'inizio della memoria video 
da mandare a schermo su schermata_a;
intanto disegno su B, e quando B e' pronta, lo imposto all'inizio di 
schermata_b.
e non mi devo neanche preoccupare di sincronizzarlo col refresh, lo fa 
la scheda in automatico: infatti disegnera' a partire da quella 
locazione appena ricomincera' il ciclo di refresh
per ulteriori info, ci sono un sacco di tutorial in rete, ne trovi a 
bizzeffe con google

 ha scritto nel messaggio
news:35300865....@tin.it...

E se non devo copiare un'intera schermata ma solo un piccolo spicchio di
appena 32x32 px nel centro dello schermo? Funziona lo stesso?

 di appena 32x32 px nel centro dello schermo? Funziona lo stesso?
ci sono le apposite funzioni di blitting per questo, supportate almeno 
per casi elementari da tutte le SV. e comunque stiamo andando OT, se 
vuoi maggiori delucidazioni chiedi su it.comp.grafica

 Quella sarebbe solo programmazione Asm e non C++!
Sarebbe giusto se il C++ comprendesse l'Assembly ma questo non è vero.
Invece è vero che comprende il C (a parte alcune piccole differenze).
EMG

 Concordate con quanto detto?
No.
EMG

Concordate con quanto detto?
No, perche' (senza offesa) hai detto un mare di fesserie.

 ha scritto nel messaggio
news:3ae814d9...@news.libero.it...

Perché secondo te
typedef int obj;
int operator +(obj x, obj y) {
  return ...;
}
non equivale a:
int sommaoggetti(obj x, obj y) {
  return ...
}
Visto che obj è un int? Mi riferivo al caso che obj non è una derivata di
qualce altro oggetto, quando non è una classe complessa ... insomma, una
cosa elementare! A me pare solo che cambia il nome!!

 casa produttrice del processore...
Comunque io non dico che sia sbagliato ottimizzare.... ma sappiamo realmente
cosa stiamo ottimizzando? O ci basiamo sui documenti relativi ai processori
80286?
E soprattutto, hai mai osservato il codice ASM generato dalla compilazione
in versione Release di un programma?
Ecco perché secondo me l'ottimizzazione ad oggi va intesa non come
istruzioni del codice... ma efficienza degli algoritmi innanzitutto!
Questo il compilatore non puň ancora farlo....
Ciao
ByZ-2K

il C++ ci offre le iostream, perché utilizzare ancora le fopen &Co.?
il fatto è che il C++ non è solo un linguaggio OO. Esso supporta anche
altri paradigmi: non è per niente declassante, è una caratteristica
del linguaggio.
Cmq siamo OT


che è molto + veloce. Per cui:
io mi aspetto che un compilatore decente scelga le istruzioni migliori
per eseguire certe operazioni: sicuramente i compilatori più recenti
implementano la prima moltiplicazione nei termini della seconda (se è
effettivamente più veloce).
Prima regola di Kerigham/Pike nel libro "Programmare nella pratica":
scrivere sempre la cosa più semplice da scrivere e comprendere


virtu' della sua maggiore potenza espressiva....
infatti, consideravo le caratteristiche favorevoli al C rispetto al
C++; altrimenti la lista era troppo lunga ;-))
Ovviamente sono d'accordissimo con il resto del messaggio


semplice farlo in C++, o meglio in OOP.
e dagli!
considera questi due prog (non testati):
#define max(x,y) ( (x) > (y) ? (x) : (y) )
void main(void) {
  int i;
  int a[10];
  for (i=0; i<10; i++) {
    a[i]=max(3,4);
  }
}
#include <vector>
template<class T> inline T max(T x, T y) { return x>y ? x : y; }
int main() {
  std::vector<int> a(10);
  // non uso volontariamente gli iteratori
  for (int i=0; i<10; i++) {
    a[i]=max(3,4);
  }
}
Come puoi vedere lo OOP non la trovi neanche se preghi. Eppure ci sono
degli ovvi vantaggi nel secondo rispetto al primo. E le prestazioni
saranno ragionevolmente identiche (forse leggermente a svantaggio del
C++ in questo semplice caso).


 risulta + semplice farlo in C++, o meglio in OOP.
Credo che sia una questione di "abitudine". Personalmente sono "cresciuto" 
con l'approccio procedurale, per cui la soluzione che mi viene di primo 
acchitto non e' propriamente ad ogetti. 
Chi si e' abituato sin dall'inizio ad una visione ad oggetti probabilmente 
ha il problema contrario.

 C++ in questo semplice caso).
Da test che ho fatto (gcc ) le prestazioni sono uguali. E comunque bisogna 
sottolineare che semanticamente parlando la versione in C++ e' piu' 
corretta.
Basta che consideri l'esempio
max(a++,b--)
...

max(a++,b--)
si, l'avevo messa apposta (anche perchè non ha molto senso usarla solo
per fare max(3,4) ;-)


corretta.
Si, si ... semanticamente, il polimorfismo, le istanze, patapim,
patapam...
La verita' e' che ce l'avete PICCOLO !  Anzi non ce l'avete proprio!
ciao, acc.   
a...@libero.it