Newsgroup: it.comp.lang.c
Titolo: c c++ Quale è la differenza?

C - C++.
Quale è la differenza?
Per imparare il C++ bisogna imparare prima C?
Saluti Gio.

Per imparare il C++ bisogna imparare prima C?
Sicuramente non e` _necessario_; molti lo trovano
_consigliabile_, opinione da cui personalmente differisco
con forza (C++ facilita la vita al principiante offrendo
costrutti ragionevolmente usabili, come string e vector;
in C, bisogna dibattersi "ab ovo" con i nudi array, la
loro allocazione/deallocazione/gestione, eccetera).
Alex

 Per imparare il C++ bisogna imparare prima C?
Be si.Il C è un sottoinsieme del C++.Quest'ultimo è stato creato dopo il 
C da Bjourne Stroustrop se non erro.Il C++ è un linguaggio orientato agli 
oggetti il C no.

 Il C++ è un linguaggio orientato agli oggetti il C no.
Vero.
EMG

 sintattico/semantiche delle quali tener conto.
Qui no nsiamo d'accordo.Il C è sotto tutti gli aspetti un sottoinsieme 
del C++ come i numeri interi sono un sottoinsieme dei numeri frazionari e 
l'insieme prende il nome di numeri relativi.
Inoltre il C utilizza tecniche di programmazione struturata;il C++ anche 
,ma vi aggiunge gli oggetti.I costrutti condizionali sono rimasti gli 
stessi(vedi if() else,switch..)quindi anche la semantica risulta uguale 
tranne se si usa la programmazione orientata agli oggetti.
P.e. printf() e cout svolgono la stessa funzione(cout ha qlc 
aggiunta,miglioria)ma cambia la sintassi non la semantica.
Quindi chi posiede un compilatore C++ possiede anche a tutti gli effetti 
un completo compilatore ANSI C.
CiauZ!

 un completo compilatore ANSI C.
Come ti ho dimostrato sopra, in senso stretto non è affatto vero.
EMG

Vero.
C++ e` multi-paradigma; la parte piu` innovativa della
libreria standard del C++, ad esempio, NON usa un
paradigma orientato agli oggetti, bensi` un paradigma
di "generic programming".  Considerare C++ come
solo "linguaggio orientato agli oggetti" e` limitante e
non bene rispondente alla realta`.  Si potrebbe forse
salvare capra e cavoli dicendo che il C++ e` ANCHE
un linguaggio orientato agli oggetti, con ricca enfasi
su quell'"ANCHE":-).
Alex

tutte,funzioni del C come printf() e poi spiegano cout << ecc.
I libri mal scritti, si`.  Quelli scritti bene, invece (ad esempio,
Lippman e Lajoie, C++ Primer 3rd Edition, Addison-Wesley, il
miglior testo introduttivo sul C++ secondo me), no (printf e`
un carnaio assurdo: perche` mai incasinare la vita di un povero
principiante con essa, quando std::cout << e` tanto + facile!).
Alex

 C++ e` multi-paradigma;
Va bene, ma qualche buona gliela dovevo pur dare all'amico... :-))
EMG




 riuscirei mai a rilasciare un programma che mi ha dato un warning in
Beato te che hai compilatori cosi` precisi e accurati sui
warning che danno... il resto di noi, usando naturalmente i
livelli piu` alti di warning (-Wall -pedantic con gcc/egcs, ecc)
e` invece purtroppo abituato a ricevere occasionali warning
"a capocchia".  Io *di solito* cerco comunque di toglierli, ma
"mai dire mai" si applica: a volte sono invece costretto a
togliere il -Werror e rilasciare comunque, nonostante il
warning:-(.
Alex

Alla fine si avranno le idee piů chiare usando printf() e imparare ad usare
Questo e` il nucleo del nostro disaccordo: personalmente, non
trovo che (per la maggior parte delle persone: la varieta` della
mente umana e` certo amplissima) imparare a usare anche
strumenti tecnicamente sgangherati, quando ne esistono altri
ottimi, fara` si` che "alla fine si avranno le idee piu` chiare".  Le
idee sui tipi, chiunque apprenda C++, se le chiarira` comunque,
e di necessita`, studiando i tantissimi costrutti del linguaggio che
appunto ai tipi sono intrinsecamente connessi; non trovo nessun
"valore aggiunto" nell'associare ad una piccola varieta` di tipi le
astruse ed arbitrarie "stringhe di formato" tipiche di printf, per non
dire di tutti gli ulteriori "bastoni fra le ruote" che printf e le sue
parenti (scanf sprintf fra tutte) impongono a chi le studia ed usa.
Il C va studiato se e solo se importa conoscerlo (ad esempio
perche` si deve fare manutenzione di codice esistente scritto
in C, ecc), non come "propedeutico" ad altri linguaggi, come C++
(o, se e` per questo, Java), che secondo me e` meglio invece
affrontare nei termini a loro propri.
Alex

 Alla fine si avranno le idee più chiare usando printf()
Più chiare su come usare printf(), non certo sul C++.
EMG


Il discorso che fai è sicuramente corretto, eppure ti posso assicurare
che non esageravo: _TUTTI_ i miei programmi vengono compilati senza
alcun warning. Mi faresti un esempio di un caso che ti è capitato per
cui hai dovuto sopportare il warning senza riuscire ad eliminarlo? Tanto
per rendermi conto di cosa stiamo parlando...
EMG

 fa parte del linguaggio. Quindi ritengo che possa essere addirittura
Una volta era cosi`; oggi, secondo lo standard ISO, le funzioni standard
fanno parte del linguaggio, come si evince da molti indicatori.  Ad
esempio, lo standard asserisce di essere "lo standard del linguaggio C"
(o "lo standard del linguaggio C++") _e basta_ (ne` nel titolo, ne` nella
breve "descrizione del contenuto", entrambe normative, si dice mai
"linguaggio e libreria", SOLO "linguaggio"): eppure lo standard precisa
anche come e` fatta la libreria; quindi, se lo standard descrive solo il
linguaggio (per propria stessa asserzione), e lo standard descrive anche
la libreria (dato empiricamente osservato), se ne deduce che "il linguaggio"
*comprende* la libreria.
Inoltre: un programma non puo` piu`, ad esempio, definire una funzione
printf (nello spazio globale dei nomi) senza perdere con cio` la sua
conformanza allo standard.  Il compilatore conosce la semantica delle
funzioni standard e puo` infatti espanderle inlinea, o eliminarle se puo`
dimostrare che non servono, ecc (non ne conosco che facciano cio`
con printf, ma e` ormai comune per funzioni come memcpy, memset,
strcmp, eccetera).
Alex

 per rendermi conto di cosa stiamo parlando...
#include <map>
#include <string>
typedef std::map<std::string,int> map_t;
bool presente(const map_t& m, const std::string& parola)
{
    return 0!=m[parola];
}
Questo banale frammento di C++, con VC++5 o 6, provoca ripetuti
warning 4796 ("identificatore piu` lungo di 255 caratteri, il debugger
lo ignorera`") visto che la "decorazione" (mangling) dei nomi del
template porta, appunto, sopra la soglia dei 255 caratteri per nome.
Naturalmente non m'importa un fico del fatto che il debugger dovra`
ignorare questi nomi artificialmente allungati, ma i warning me li
devo tenere (o sopprimerli artificialmente con un #pragma, ma
questo, come compilare con "togli tutti i warning", non e` in genere
un procedimento molto saggio... inoltre gli header di sistema a loro
volta usano il #pragma warning, per cui, a meno di non alterare gli
header di sistema [!], a volte i warning "riaffiorano" comunque).
Un altro esempio: quando un header di sistema (siamo sempre
li`...!-) usa una estensione non-standard al linguaggio (ad esempio,
in C, una union anonima), un buon livello di warning ti avvertira` del
fatto _ogni volta che includi il dato header di sistema_... "soluzioni":
alterare gli header di sistema, tenersi il warning, o abbassare il
livello di warning del compilatore, tutte molto spiacevoli.
Alex

 Come ti ho dimostrato sopra, in senso stretto non è affatto vero.
Be'con qualche aggiunta,come tu stesso hai riportato sopra,è vero.

 fanno parte del linguaggio, come si evince da molti indicatori.
Ok, grazie della correzione. Spero comunque che il succo del discorso
che facevo non cambi.
EMG

 livello di warning del compilatore, tutte molto spiacevoli.
Chiaro. Anche qui però siamo in presenza di elementi fuori dallo
standard. E' questo il problema, secondo me...
EMG

 o 6 Microsoft non ho ancora provato,cmq mi fido della tua nota.
Normalmente non è buona cosa prendere come buono il comportamento di un
compilatore. L'unico riferimento competente è la documentazione
ufficiale dello standard.
EMG

...
    [snip]

Infatti, non cambia (e in effetti mi trova d'accordo: le funzioni
variadiche, di qualsiasi cosa "facciano parte", sono delle petecchie).
Mi limitavo a correggere una "indicazione collaterale" che, un tempo
giusta (e per questo si trova in tanti libri ancora oggi) non e` piu`
applicabile ai linguaggi C e C++ come definiti dagli Standard.
Alex

 standard. E' questo il problema, secondo me...
Il C++ non comprende nel suo Standard schemi di accessi a database,
GUI, reti, eccetera; tutti questi devono essere necessariamente usati
"fuoribordo", tipicamente includendo header di sistema (o di librerie,
commerciali o gratuite, offerte da terze parti).  "Il problema", se tale
e`, e` dunque complessivamente ineliminabile.
Secondo me, "il problema" sono almeno due:
1. i compilatori sono imperfetti,
2. la decisione se dare o meno un warning (che lo Standard lascia del
    tutto e per tutto al compilatore) tiene conto di "utenze" diverse, e,
    come tutti i compromessi, e` spesso intrinsecamente imperfetta.
Ad esempio, e` ragionevole pensare che un compilatore offra dei
warning se una funzione non usa uno dei propri argomenti, visto
che questa e` probabilmente una distrazione del programmatore;
ma certe volte una funzione DEVE accettare argomenti di numero
e tipo predefinito, affinche` l'indirizzo di quella funzione possa
venire posto in un certo puntatore, anche se uno degli argomenti
non interessa.  Qui, il C++ offre la soluzione (basta non dare un
nome all'argomento "inutile" nella definizione della funzione) ma
in C questo non si puo` fare, quindi la situazione e` insolubile in
modo portabile.
Supponiamo, ad esempio, di avere questa situazione:
typedef int (*pfunz)(int, int);
int pippo(pfunz);
e dobbiamo passare a pippo l'indirizzo di una funzione che
"di natura" ignora il proprio secondo argomento:
    int soloprimo(int a, int b) { return a; }
Alcuni compilatori C non daranno mai il warning in questione
(peccato, un'opportunita` sprecata di correggere errori); altri
permetteranno di sopprimerlo ad esempio aggiungendo una
istruzione del tipo
    b=b;
nel corpo della soloprimo -- ma proprio questa in altri ancora
*causera`* un warning ("assegnamento di b a se stesso e`
senza effetto e viene ignorato"), e in alcuni, magari, con degli
ottimizzatori scemi, un paio di istruzioni macchina in piu`, del
tutto inutili, ecc ecc.  In C++, come dicevamo, basta scrivere:
    int soloprimo(int a, int) { return a; }
senza dare un nome al 2o argomento, ma questo non e`
Standard in C (e questo, tutto sommato, e` un gruppo sul
linguaggio C).
Situazioni analoghe, in cui un compilatore decide di avvertire
su di un comportamento perfettamente corretto ma spesso
sintomo di errori, ne capiteranno sempre; e non esiste un modo
portabile di evitare questi "avvertimenti", se non sopprimere i
warning, cura peggiore del male.
Alex

 linguaggio C).
Scusa, non ho capito questa frase. Che significa "e` un gruppo sul
linguaggio C"? Gruppo in senso matematico? Puoi chiarirmi?
EMG

 linguaggio C"? Gruppo in senso matematico? Puoi chiarirmi?
it.comp.lang.c e` un "gruppo di discussione" (in inglese, un
"newsgroup") il cui scopo e` la discussione del linguaggio C,
del suo uso, ecc.  Non credo che si tratti di un gruppo in
senso matematico, no:-).  Comunque, il punto che intendevo
sottolineare e` che le discussioni di C++ dovrebbero farsi
sul "gruppo" (newsgroup) it.comp.lang.c++, non qui, cioe`
su it.comp.lang.c.
Alex

 "newsgroup") il cui scopo e` la discussione del linguaggio C,
Ops! Che idiota... (velo pietoso che scende...)
EMG

appunto, avevo capito male. Comunque non è affatto difficile eliminarli.
In C++ no (appunto per questo scopo si puo` lasciare un parametro
*anonimo*: per dire che c'e` ma non lo si usa), e` invece atrocemente
difficile in C (lasciare un parametro anonimo viola la sintassi standard
del linguaggio C).  Alcuni compilatori pretendono che io "faccia vedere
che uso davvero" il parametro che in realta` voglio ignorare, ad
esempio con piacevolezze del tipo
    b;
oppure
    b=b;
e allora smettono di darmi il warning; altri, pero` (e, dagli torto!), si
METTONO a darmi dei warning se uso simili statement strani e
difficilmente spiegabili...!
Il C++, naturalmente, ha i problemi suoi in tema "warning strani
per idiomi normali".  Puo` darsi, come altrove ipotizzi, che il fatto
che tu non ne abbia mai incontrati deriva da quello che hai usato
pochi compilatori diversi, e poca varieta` di "idiomi normali" (ti
posso suggerire Coplien, "Advanced C++", per trovarne tanti:-).
Alex

 posso suggerire Coplien, "Advanced C++", per trovarne tanti:-).
Sicuramente gli "idiomi normali" che uso io sono di livello molto più
semplice di quelli a cui ti riferisci tu (e dei quali mi hai dato dei
gustosi assaggi...). Comunque mi piacerebbe si leggere il Coplien. Forse
prima o poi riuscirò a farlo (come dovrei fare tante altre cose... :-(
).
EMG

 prima o poi riuscirò a farlo (come dovrei fare tante altre cose... :-(
E` stato definito "il libro LSD": e` viola, e ogni volta che lo usi ti
espande la mente:-).  Pero`, per fortuna e a differenza dell'LSD,
e` anche legale:-).  Purtroppo parla di versioni antiche di C++, e
Coplien non ha interesse ad aggiornarlo (oggi si occupa di cose
piu` astratte, come i paradigmi di progettazione; ottimo il suo ultimo
libro, "Multi-paradigm design for C++"); nondimeno, e` forse l'unico
libro di "C++ all'antica" che si puo` ancor oggi consigliare.
Alex

 Penso che differiamo: io non sceglierei mai "nessun warning".
Quindi preferisci un compilatore che ti costringe ad accettare come
andata a buon termine una compilazione piena di warnings? Sono sicuro di
no. E, da quello che dici, mi sembra di capire che l'unico modo di non
averli sia che il compilatore ci pensi due volte prima di darli.
Sbaglio?
EMG