Newsgroup: it.comp.lang.c
Titolo: [newbie] Dubbio: C o C++ e altro...

Ciao a tutti e ancora grazie a chi mi ha risposto!
Avrei un'altra cosetta da chiedervi: oggi ho visto in libreria il libro
"Teach yourself C++ in 24 hours" della collana SAMS, che promette di
insegnare il C++ in 24 lezioni da un'ora ciascuna, ed è indicato per
principianti assoluti, come me.
Ora, io vorrei imparare a programmare per diletto e sto iniziando col C,
però ho letto che il C++ offrirebbe molto di più in termini di prestazioni e
inoltre si trovano "oggetti" già pronti, modificabili per le proprie
esigenze.
Leggendo le prime pagine del libro in questione, mi è sembrato ben fatto e
adatto anche a chi non sa nulla di programmazione, e mi ha colpito una frase
che suona più o meno così: "è opinione comune che per imparare il C++ si
debba prima conoscere il C, ma questo non solo non è necessario, è anche
dannoso"...
Quello che vi chiedo è: le cose stanno davvero così ?
Conoscete questo manuale ?
Ammettendo di imparare il C++, sarà poi faticoso imparare successivamente
anche il C ?
Grazie e scusatemi per la lunghezza del post.
Ciao!
Andrea Massucco      
and...@dircon.co.uk
      ICQ: 31185185
################################################
# gaudeamus maxime in nomine Bacci, Tabacci Venerisque #
################################################

anche il C ?
Piu' che altro, non credo che dopo ti servira' imparare il C ! ;)
Andrea Laforgia
-------------------------------------
(grattatio pallarum omnia mala fugit)
--
Posted from 
itaca.ulysse.it
 [195.223.254.1]
via Mailgate.ORG Server - 
http://www.mailgate.org

 anche il C ?
Ogni passaggio di apprendimento è impegnativo. Impegnativo non vuol dire
che sia faticoso, la fatica dipende dalla voglia che hai di affrontare
l'impegno. Personalmente quando mi applico per apprendere un nuovo
linguaggio (o nuovi aspetti di un linguaggio che già conosco) posso
impegnarmi per giorni, mesi... ma quasi mai faccio fatica.

linguaggio (o nuovi aspetti di un linguaggio che gi` conosco) posso
Non credo proprio che il C possa essere considerato un linguaggio che introduce
"nuovi aspetti" rispetto al C++ (semmai "vecchi aspetti" ;) .
Io non vedo, sinceramente, la necessita' di andare all'indietro, anziche' in
avanti.
Una volta imparato il C++ basta quello !
Questo vale se si punta all'evoluzione del proprio stile di programmazione.
Se poi si vuole accrescere il proprio bagaglio culturale, allora va bene.
Sempre, pero', che quest'ultima operazione non sia, per l'appunto, dannosa ! ;)


 Una volta imparato il C++ basta quello !
Non sono d'accordo. E' appurato che C e C++ sono linguaggi diversi per
filosofia e approccio: questo significa che si dirigono anche a target e
soluzioni diverse. Con il C++ non si risolvono tutti i problemi allo
stesso modo con cui si risolvono con il C, spece se si cerca le
prestazioni, ottimizzazione e compattezza del codice finale.
Il kernel di linux, ad esempio, č scritto rigorosamente il C. Sebbene
sia un grosso progetto, nessuno si sogna (almeno mi pare) di riscriverlo
in C++. E non credo proprio che stiamo parlando di progetti obsoleti.

 anche il C ?
Assolutamente no. Anzi, te lo troverai praticamente già fatto dato che
il C è all'incirca un sottoinsieme del C++.
EMG

 dimestichezza con il mezzo che poi si dovrà condurre. 
Io credo ci sia un equivoco di fondo. Il C++ ha la caratteristica di
mantenere (se si vuole) la logica e semantica del C, quindi è logico
pensarlo come una "estensione" se non addirittura una "evoluzione".  
Il fatto è che il C++ "spinto" nelle sue caratteristiche peculiari è un
linguaggio abbastanza diverso dal C. E come succede per i linguaggi
diversi, è matematico che siano più o meno adatti ad una o l'altra
soluzione. Un po' come il tuo esempio guidare una 500 o un camion sono
due cose diverse, ma non vuol dire che guidare il mezzo più grosso sia
la soluzione a tutti i problemi di trasporto (ovviamente). 
In fidonet (PRG.ITA) c'è stata recentemente una lunga discussione
sull'opportunità di scrivere un kernel in C++. In effetti c'è da
chiedersi perchè il kernel di linux non è analizzato ad oggetti e
realizzato in C++, bensì in C puro. La ragione è semplice: la logica "ad
oggetti" è un'ottima soluzione per il programmatore ma non per il
compilatore. Un codice realizzato in C++ (ovviamente scritto con la
logica peculiare di questo linguaggio) è sicuramente ottimizzato in
maniera peggiore.

 maniera peggiore.
questo sarebbe il meno. 
perché migliorando la qualità dei compilatori (e nel tempo questo è 
un obiettivo raggiungibile) il problema sparirebbe.
ma, come giustamente osserva linus nell'intervista che ti riporto qui
sotto (presa dal linux journal di luglio 98), c'è il problema, ben
più grave, della eccessiva *complessità intrinseca* del linguaggio.
questo è il principale motivo per cui il C++ non sarà probabilmente mai
usato per sviluppare sistemi operativi (al riguardo è interessante
notare come anche la m$ la pensi allo stesso modo - basta ricordare le
dichiarazioni su un eventuale sviluppo in C++ del kernel di nt, da parte 
del suo famoso capo-progetto).
giulio
==============================
In molti si chiedono come mai il kernel è scritto in C e non in C++. 
Quai sono i motivi contrari all'uso del C++ nel kernel? 
[ Risponde Linus Torvalds ]
Il C++ avrebbe permesso di usare alcune funzionalità del compilatore che 
mi sarebbero piaciute, in effetti il C++ è stato usato per un breve lasso 
di tempo, poco prima di distribuire Linux-1.0, ma non si è rivelata una 
scelta molto utile e non credo che ci proveremo ancora in futuro, per 
svariate ragioni. 
Un motivo è semplicemente che il C++ è molto più complesso del C, e il 
compilatore spesso fà cose di nascosto dal programmatore che non sono 
affatto ovvie quando si guarda il codice localmente. Sì, si possono evitare 
cose come le classi virtuali e quindi semplificare la situazione, ma la 
questione è semplicemente che il C++ permette molte cose che il C non 
permette, e questo può rendere più difficile successivamente trovare le 
cause dei problemi. 
Un altro motivo della scelta è collegato al precedente, e si tratta della 
velocità e della stabilità dei compilatori. Il C++, essendo un linguaggio 
molto più coplesso, ha una propensione per avere compilatori con molti più 
errori, inoltre la compilazione è solitamente più lenta. Questa può essere 
considerata una questione di implementazione del compilatore, ma la 
complessità di fondo del linguaggio è certamente un cosa che può essere 
considerata oggettivamente dannosa per lo sviluppo del kernel. 
-- 
Boycott Microsoft: 
http://www.boycott-ms.org/

 sono cronologicamente antecedenti.
Però chi conosce il C++ praticamente conosce anche tutto il C.
EMG

Enrico Maria Giordano (
e.m.gi...@flashnet.it
) wrote:
[ snip ]
: Assolutamente no. Anzi, te lo troverai praticamente già fatto dato che
: il C è all'incirca un sottoinsieme del C++.
Fermo restando che ci sono una serie di sottili differenze che possono
complicare la vita, passando da un linguaggio all'altro. Mi ricordo di
una serie di articoli sul C/C++ User Journal a questo proposito.
Esempio classico:
int pippo();
ha significati diversi in C e in C++.
Ciao ciao,
Andrea
-- 
"...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and 
 the Ugly)."
(by Matt Welsh)

 maniera peggiore.
Eppure ho letto diverse volte il contrario e anche Alex Martelli tempo
addietro asseriva che addirittura il C++ potesse essere più ottimizzato
del C, portando l'esempio concreto (con tanto di benchmark) della
gestione delle stringhe in C (con i char *) e in C++ (con il tipo
string).
EMG

 cause dei problemi.
Naturalmente mi guardo bene dal mettermi anche solo lontanamente a
confronto con Linus ma nelle righe sopra mi sembra vagamente di
intravedere una scarsa dimestichezza con il C++. Secondo me è questa la
causa principale di tutti quei dubbi. Posso sbagliare, ovviamente...
EMG

in C++. E non credo proprio che stiamo parlando di progetti obsoleti.
In questo caso e' stato scelto il C rispetto al C++ solo per la compattezza e
velocita' del codice.
Se e' per questo, riscrivilo in assembly e generi codice ancora piu' compatto e
veloce.
Ricordati che il C e il C++ sono come due robot che costruiscono automobili,
l'una le fa pezzo per pezzo, l'altra per pezzi prefabbricati.
Forse la prima sara' piu' rifinita, piu' aerodinamica, ma la strada su cui
corrono e' la necessita' di utilizzo non cambiano.


maniera peggiore.
Quello che dici e' irrilevante con la discussione tra la differenza dei due
linguaggi in quanto io potrei trovare nel linguaggio assembly un alleato piu'
forte del C per scrivere codice ottimizzato e compatto, in barba a tutti i
compilatori.


Posso dirti alcune cose che riguardano la mia esperienza, tutt'ora in
evoluzione.
Io studio il Pascal all'Università e il C e il C++ a casa, quando ho tempo.
Ovvio che per conoscere bene un linguaggio ci vogliono anni di preparazione,
ma per iniziare a fare qualche programma non troppo difficile non ci vuole
molto tempo. La cosa difficile è progettare algoritmi efficienti sfruttando
al massimo le potenzialità che il linguaggio ti offre.
Io il pascal lo conoscevo poco e male alle superiori (pensa che credevo
fosse Turbo Pascal il linguaggio...) eppure io ho imparato per bene tutta la
sintassi in pochissimo tempo, senza seguire le lezioni. A questo punto puoi
farlo anche tu.
Per il resto, ti consiglio di leggere anche qualche buon libro che aiuti a
imparare le tecniche di progettazioni di algoritmi, che ti illustri una
buona tecnica di programmazione e un libro con tanti spunti per esercizi,
che non fanno mai male.
San Vegeta from Hell
http://www.geocities.com/Area51/Dungeon/8436
(da visitare con un browser della Netscape)

veloce.
Perchè il C è più veloce del C++?


 più grave, della eccessiva *complessità intrinseca* del linguaggio.
Sono d'accordo (e come non potrei, se non lo sa lui come si scrive un
kernel... :-)))

 corrono e' la necessita' di utilizzo non cambiano.
Lo dici te che non cambiano. A seconda dell'utilizzo l'aerodinamica
potrebbe essere *molto* critica, non credi?

 compilatori.
Non mi pare un discorso molto carico di significato.
Io ti dico che il C produce un codice più compatto e performante. Tu
dici che ciò è insignificante nel confronto fra i due linguaggi, e già
questo è abbastanza discutibile. Poi giustifichi l'affermazione dicendo
che con l'assembly puoi scrivere un codice ancora più compatto. Che vuol
dire?
Sarebbe come se nel confronto fra una ferrari e una 500 io dicessi che
la ferrari è più veloce, e tu "la velocità è irrilevante nel confronto
fra le due auto, perchè io potrei prendere un jet in barba a tutte le
automobili".

 kernel... :-)))
:-)
giulio


 string).
beh, mi sarebbe piaciuto vederlo, questo esempio :-) non perchè non ci
creda ma proprio perchè ci credo troppo... il risultato è fin troppo
scontato ancor prima di provare.
Sappiamo come la gestione C standard delle stringhe (vettori carattere)
è dispendiosa. E' chiaro che se confronti le prestazioni di una strlen
contro una string.getLength() (esempio) la bilancia pende decisamente
verso la seconda: sicuramente il tipo string mantiene una variabile con
la lunghezza della stringa, mentre strlen si scorre il vettore fino alla
ricerca del terminatore. Mi auguro non stata fatta una prova di
confronto del genere, perchè vuol dire che avevano davvero tempo da
perdere (beati loro) :-)
In C è possibile implementare una gestione delle stringhe, non sarà
orientata ad oggetti, non avrà certe caratteristiche tipiche del C++
(utilissime al programmatore, ma questo non lo discuto affatto) ma si
può fare. In quel caso si potrebbe fare il confronto prestazionale.

potrebbe essere *molto* critica, non credi?
Se si esclude il discorso di Linux o di progetti di quel genere, in cui e'
necessaria una grossa compattezza e un'alta velocita' del codice, allora puo'
essere preferibile il C al C++, ma se si confronta il tipo di approccio
progettuale che offrono i due linguaggi, non ci sono dubbi : il C++ e' molto
meglio.
Per progetti molto grandi conviene usare il C++, magari a discapito della
compattezza del codice, se puo' aiutare nella fase di progettazione, di
collegamento tra i team e di manutenzione.
E' in questo che consiste la sua superiorita' rispetto al vecchio linguaggio.


automobili".
Forse hai perso un po' di vista i termini del confronto.
Originariamente non si stava parlando di velocita' e compattezza del codice ma
del C++ come linguaggio migliore del C.
E questo e' innegabile, dato che le migliorie al codice che il C++ apporta,
rispetto al C, sono evidenti.
Il C++, inoltre, viene utilizzato per progetti molto complessi, per i quali e'
trascurabile la velocita' e compattezza del codice a favore della facilita' di
progettazione.
Poi, tra l'altro, non credo che il C++ sia cosi' poco "performante", rispetto al
C.
Ti cito Richard Wiener e Lewis Pinson che hanno scritto "An introduction to
Object Oriented Programming and C++" pubblicato dalla Addison Wesley e sono
entrambi docenti di Computer Science all'Universita' del Colorado, direttori di
riviste del settore e dei quali Pinson e' fondatore della Computer Intelligence
Company, i quali riportano testualmente :
"Il linguaggio C++ va oltre l'Ada e il Modula-2, mantenendo al tempo stesso la
notevole compattezza e velocita' d'esecuzione caratteristiche del linguaggio C".
Evidentemente, a questo punto, bisogna vedere che compilatore usava Linus ! ;)


 Evidentemente, a questo punto, bisogna vedere che compilatore usava Linus ! ;)
Perchè parli al passato? E poi il kernel di linux l'ho compilato anche
l'altro ieri sera...

Un altro esempio (sempre di Alex) verteva sull'uso di qsort; sia in C
puro che in C++ devi passare un puntatore ad una funzione di
confronto, ma la funzione in C++ puo' essere inline --- con un
risparmio di tempo non indifferente.  Avverto pero' che nel draft del
nuovo standard C (C9X) e' presente una nuova keyword inline ...
Non bisogna poi dimenticare che un uso giudizioso della STL fa
risparmiare la reinvenzione di parecchie ruote, ovvero il riuso di
codice per linked lists, sets e simili contenitori.
Ricordate pero' che non esiste un linguaggio "da preferire" di per se,
ma che ogni contesto puo' suggerire il linguaggio appropriato.  Magari
se lavorate in banca il linguaggio migliore e' il COBOL (ugh! :-)
-- 
Maurizio Loreti                      
http://wwwcdf.pd.infn.it/~loreti/mlo.html
Un. of Padova, Dept. of Physics - Padova, Italy          
lor...@padova.infn.it

 risparmio di tempo non indifferente.  
Hai detto bene, può essere :-) normalmente il compilatore non garantisce
che la keyword verrà rispettata. In fase di ottimizzazione deve sempre
valutare se conviene o no, e non sempre ci azzecca (tempo fa stavamo
vendendo proprio un esempio a proposito con un amico in cui il gcc
compilava funzioni inline in modo un po' troppo "fiscale").
Comunque è corretto, la presenza dell'inline è un punto a favore del
C++. 


 ha significati diversi in C e in C++.
Giusto: in C significa che la funzione prende un numero imprecisato di
argomenti mentre in C++ significa che non ne vuole nessuno. Per
esprimere in C che non si vuole alcun argomento bisogna specificare
esplicitamente
int pippo( void );
Di contro, se in C++ si vuole un numero imprecisato di argomenti si deve
scrivere
int pippo( ... );
EMG

 Perchè il C è più veloce del C++?
Mah, secondo me no. O meglio, ci sono alcuni punti nel C++ che
richiedono necessariamente un overhead, come le funzioni virtuali. Ma
credo che a parità di utilizzo questo non sia affatto vero.
EMG

 Perchč il C č piů veloce del C++?
No, non fraintendere: questo non č vero. 
Io ritengo che implementare del codice in C++ usando a pieno le sue
caratteristiche (anche in fase di analisi) comporta inevitabilmente un
innalzamento del livello di astrazione. Scrivere un programma in C++ ad
oggetti *non* aiuta certamente il compilatore.  
Con questo non voglio assolutamente mettere in discussione il C++ e il
paradigma OO, ci mancherebbe altro... si tratta di strumenti
preziosissimi in mano ai programmatori.
Perň giustamente non bisogna mai perdere di vista il fatto che ogni
problema puň avere una soluzione diversa. Il C++ non integra o
sostituisce al 100% il C.

Velocit` e compattezza di codice sono dei vantaggi, mica noccioline...
Indubbiamente, ma che confrontati con le facilita' offerte per la progettazione
possono risultare poco importanti.
E questo vale, solitamente, per linguaggi fortemente orientati agli oggetti.
Ripeto, comunque, che sono dubbioso sul fatto che il C++ sia cosi' poco
"performante" rispetto al C.
Bruce Eckel in "Thinking in Java" :
"The designers of the C++ language, trying to woo C programmers (and most
successfully, at that), did not want to add any features to the language that
would impact the speed or the use of C++ in any situation where C might be used.
This goal was realized, but at the price of greater complexity when programming
in C++. Java is simpler than C++, but the tradeoff is in efficiency and
sometimes applicability. For a significant portion of programming problems,
however, Java is often the superior choice."


valutare se conviene o no, e non sempre ci azzecca (tempo fa stavamo
Io credo proprio che non sia il compilatore a valutare la convenienza della
funzione inline.
Credo che i casi in cui il compilatore non sostituisca localmente la chiamata di
funzione con il suo codice siano dovuti ad incapacita', di quel particolare
compilatore, nel trattare la funzione inline.
Questo accade, per esempio, per funzioni inline ricorsive.
E comunque il compilatore, nel caso non ci riesca, avvisa con un warning, il che
significa che la valutazione dell'uso o meno della caratteristica inline non
viene lasciata ad esso.


, 
postato su comp.unix.programmer.
Cosi' come e' scritto gira su SunOS 5.6, compilato con gcc 2.8.1.
[ snip ]
: Mi auguro non stata fatta una prova di confronto del genere, perchè 
: vuol dire che avevano davvero tempo da perdere (beati loro) :-)
8)


 funzione inline.
Invece io ho sempre letto che è proprio il compilatore che considera la
direttiva inline un suggerimento e valuta caso per caso se sia opportuno
applicarla.
EMG

Grazie per le vostre risposte, veloci e soprattutto numerose!
Scusatemi se non rispondo singolarmente, ma aggiungerei davvero troppi mex.
;-)
Come prevedevo, anche tra di voi non c'è unità di vedute sull'argomento, ma
penso sia normale e comprensibile ;-)
Per ora mi sono scaricato Tricky C e quindi cercherò di tirare avanti col C.
Nel frattempo mi piacerebbe sapere qualcosa anche a proposito di Java, ma
non credo che questo sia il NG adatto...o possiamo fare un leggero OT? ;-)
Ciao!
Andrea Massucco      
and...@dircon.co.uk
      ICQ: 31185185
################################################
# gaudeamus maxime in nomine Bacci, Tabacci Venerisque #
################################################

non credo che questo sia il NG adatto...o possiamo fare un leggero OT? ;-)
Sempre che it.comp.lang.java non si arrabbi ! ;)


applicarla.
In effetti su "Thinking in C++" di B. Eckel c'e' scritto :
"It is important to understand that an inline is just a suggestion to the
compiler; the compiler is not forced to inline anything at all. A good compiler
will inline small, simple functions while intelligently ignoring inlines that
are too complicated. This will give you the results you want - the true
semantics of a function call with the efficiency of a macro."
In effetti questo fonde i nostri due discorsi.
Cioe', il caso in cui il compilatore non compie la sostituzione in linea e'
quando la funzione e' troppo complessa.
Per funzioni abbastanza semplici, pero', non ha motivo per non farla.
La sottile differenza che ci tenevo a precisare e' che, quando una funzione puo'
essere sostituita in linea, viene fatto per certo e non costituisce
un'alternativa.
Andrea Laforgia
-------------------------------------
(grattatio pallarum omnia mala fugit)
--


Andrea Laforgia
