Newsgroup: it.comp.lang.c++
Titolo: m'acculturo?

Un saluto a tutto il NG,
so di fare una domanda trita e ritrita ma credo che il modo migliore per 
iniziare l'approccio a questo linguaggio di programmazione si quello di 
farsi guidare da chi ha più esperienza. Naturalmente prima di farvi questa 
domanda mi sono preparato a ricevere anche caxxiate ed insulti oltre, spero, 
a delle buone indicazioni. Tempo permettendo seguo in vostri thread ma, data 
la mi scarsissima conoscenza dell'argomento, le informazioni che riesco a 
carpirvi sono veramente poche. Vengo al dunque.
Programmo in C da c.a. 20 anni e credo di avere una discreta dimestichezza 
nel suo utilizzo. Ho, in questo periodo, un po' di tempo da dedicare a me ed 
ho pensato, finalmente, di avvicinarmi al C++. A tal proposito ho girollato 
per internet alla ricerca di un manuale e mi sono trovato in una foresta di 
manualistica più o meno consigliata e qualcosa ho provato anche a leggere. 
Quel che mi piacerebbe trovare è un manuale di C++ scritto per chi il C già 
lo conosce con ricchi esempi, esercizi e soluzioni, possibilmente in 
italiano (quest'ultima cosa per pigrizia). Naturalmente se quello che 
secondo voi è il migliore lo si può trovare solo in una libreria allora 
benvenga il suo titolo, autore, ecc.
Vi ringrazio anticipatamente per le risposte e per gli aiuti . Vado a 
procurarmi scafandro e scudo (per gli sputi ed il lancio di oggetti)
Un saluto,
Maxime. 

 benvenga il suo titolo, autore, ecc.
Di solito quelli consigliati sono questi:
http://www.emagsoftware.it/faqcpp.htm#7
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg
The EMG Music page:         
http://www.emagsoftware.it/emgmusic
 

 Maxime.
No, nessuno sputo e tanto meno insulti!
Manuali ce ne sono tanti e ti daranno buoni consigli su questo NG. Io 
invece te ne do un altro: nella tua frase - "...mi piacerebbe trovare è 
un manuale di C++ scritto per chi il C già lo conosce..." potrebbero 
nascondersi alcune insidie.
C e C++ hanno in comune molto meno di quanto chi programma col primo pensi.
E' vero che "banalizzando" il set d'istruzioni è lo stesso con qualche 
aggiunta, ma è la concezione della programmazione ad essere 
profondamente differente, quindi io ti consiglio di partire comunque da 
zero! La tua esperienza di programmatore tornerà buona in seguito, ma 
assicurati di non fare come fanno tanti che dicono di scrivere programmi 
in C++ ma continuano a programmare in C !
Io anni fa ho fatto lo stesso salto che ora vuoi fare... sinceramente 
pensavo di aver capito tutto dopo poche ore, perchè sapevo già molto 
bene il C, ma solo dopo un pò di tempo ho cominciato a capire come 
andavano le cose...
ciao.

italiano (quest'ultima cosa per pigrizia).
L'italiano ovviamente scordatelo. Il mio consiglio è "C++ Primer
4^ed." di Stanley Lippman e Josée Lajoie.

andavano le cose...
Il problema è che la programmazione ad oggetti, in generale, richiede
l'apprendimento di una mole tale di informazioni specifiche che la
semplice conoscenza del C è un presupposto quasi insignificante.

 semplice conoscenza del C è un presupposto quasi insignificante.
Appunto, mi pare che sia una questione sulla quale concordare. Non a 
caso era il consiglio che davo al nostro amico.
ciao.

 semplice conoscenza del C č un presupposto quasi insignificante.
Non sono d'accordo.
Nella mia esperienza, chi conosce gia' bene il linguaggio C diventa piu' 
rapidamente un buon programmatore C++ rispetto a chi non conosce affatto 
la programmazione o conosce solo la programmazione in Visual Basic o in 
COBOL.
Conoscere il C significa conoscere i tipi di dati fondamentali, tra cui 
gli ostici puntatori, e le istruzioni di controllo, che rimangono anche 
in C++, e che richiedono un certo tempo per essere apprese.
-- 
     Carlo Milanesi
 
http://digilander.libero.it/carlmila

 in C++, e che richiedono un certo tempo per essere apprese.
Beh, le istruzioni di controllo, scusa, ma ci sono un po' in tutti i
linguaggi imperativi. E non credo che a qualcuno con 20 anni di
esperienza attiva di programmazione (in quasi qualunque cosa) questo
possa o debba dare problemi.
Per i puntatori... si. Ma se uno si mette pure nell'ordine idee di
usarli *il meno possibile*, non casca male, IMHO. 
-- 
-riko

 4^ed." di Stanley Lippman e Josée Lajoie.
Mi accordo.
Prima o poi dovrebbero tradurlo, comunque. 
-- 
-riko

 4^ed." di Stanley Lippman e Josée Lajoie.
Senza dimenticare Barbara Moo, che e' coautrice di questa edizione. Lo
scrivo perche' insieme al marito Andrew Koenig sono in qualche modo
iniziatori, col loro "Accelerated C++", di una rivoluzione nel modo di
insegnare il C++ che si sente anche nell'impostazione di questa
edizione del libro, che e' sostanzialmente rifatto rispetto alla
precedente, che gia' non era male.
Questo e' l'aspetto che lo rende ideale per chi e' nella posizione
dell'OP, anche se potrebbe trovarsi un po' spaesato nel partire da
concetti che non conosce per ritrovare le cose piu' familiari relegate
verso il fondo del libro. Penso pero' che sia il modo migliore per
partire col piede giusto.
Ciao,
Nicola

Ciao,
non mi sono dimenticato di rispondervi e tanto meno di ringraziarvi per i 
suggerimenti ed i consigli, solamente tentavo di raccapezzarmici. Prima mi 
sentivo in mare su di una barca senza remi ora ho ritrovato i remi ma con la 
barca sono in un bosco fitto.
Innanzitutto ringrazio Enrico Maria Giordano per avermi proposto un link che 
durante le mie ricerche non avevo incontrato. L'ho letto, credo, con la 
dovuta attenzione e mi sono proposto di riscorrerlo, sopratutto in questi 
inizi, per non ripropormi con domande già trattate.
Ringrazio inoltre Andrea Laforgia, Enrico Franchi e Nicola Musatti ai quali 
rivolgo un saluto particolare per il piacere di rileggerli dopo parecchio 
tempo (a causa mia). Ho ricercato in rete commenti relativi al libro e 
sembra esser tenuto in buon conto da molte persone quindi non mancherò di 
procurarmene una copia anche se mi pare di aver inteso che non sia 
particolarmente indicato per un approccio iniziale.
Infine ringrazio Paolo per avermi fatto notare giustamente l'insidiosità di 
una mia frase. Con la frase
"... come fanno tanti che dicono di scrivere programmi in C++ ma continuano 
a programmare in C ..." in effetti hai, in parte, descritto anche me. Non 
per il fatto che sostengo una cosa e ne faccio un'altra ma perché non 
avendo, praticamente, mai lavorato in sede, mi sono trovato ad improvvisare 
in realtà, usi e costumi differenti. Tra queste anche il VC++ di µsoft col 
quale ho cominciato ad approfittare della comodità delle classi (es: per 
"giocare" con le stringhe è più comodo usare la CString piuttosto che andare 
di strcpy, strcat, sprintf, ecc...) a meno che non mi fosse espressamente 
negato.
Il punto è che non sono stato chiaro in una parte che tenterò di chiarire. 
Nell'attesa di acquistare il libro suggeritomi ho scaricato e cominciato a 
leggere "Thinking in C++" ed ho notato che è particolarmente improntato 
sull'approccio analitico dei problemi ma avendo io scritto quasi 
prevalentemente librerie utilizzo già quella tipologia di analisi. Ecco che 
così forse riformulando ora la domanda riesco ad essere più chiaro: esiste 
un testo sfrondo da approcci alle analisi e di spiegazioni di C? Una sorta 
di bignami insomma.
Bene. Mi preparo ai vari improperi che riceverò per aver seminato in giro 
codici ibridi e colgo l'occasione per ringraziare e salutare ancora tutti.
Maxime. 

* OT *
P.S.:
Conoscete un buon programma free per gestire i NG ?

rapidamente un buon programmatore C++ 
Dipende che cosa intendi tu per "buon programmatore C++". Un buon
programmatore C++ è uno che conosce bene i principi di programmazione
orientata agli oggetti implementati in questo linguaggio. Un buon
programmatore "ad oggetti" è una persona che conosce idiomi,
paradigmi, pattern. Per l'apprendimento di tutta questa mole di
informazioni serve molto tempo ed esperienza. Conoscere il C significa
conoscere solo la punta infinitesima dell'iceberg.

Prima o poi dovrebbero tradurlo, comunque. 
Credo sia stato già fatto, ma mi sono disinteressato delle traduzioni
eoni fa.

dell'OP
Sì, è un ottimo libro, molto meno dispersivo della terza edizione. Ci
tengo a sottolineare che è giusto un "primer", cioè chiudendo l'ultima
pagina non rimane altro che una conoscenza profonda delle basi del
linguaggio. E' ovviamente già moltissimo, ma poi bisogna integrare con
altri testi.

particolarmente indicato per un approccio iniziale.
Se parli di "C++ Primer", tutt'altro. Quel "primer" dovrebbe farti
capire il perché è adattissimo a chi inizia.

 eoni fa.
In questo caso ho un buon motivo: diciamo un motivo didattico. Al primo
anno non sono pazzamente entusiasti di libri in inglese, IMHO.
-- 
-riko

Andrea Laforgia ha scritto:

Io penso che, per quanto non abbia senso parlare di "analisi orientata 
agli oggetti" (OOA) come fanno alcuni (nessuno dei presenti), ha pur 
senso distinguere tra "programmazione orientata agli oggetti" (OOP) e 
"progettazione orientata agli oggetti" (OOD). Per quanto in piccoli 
progetti la stessa persona svolge i compiti di analista, progettista, 
programmatore e collaudatore, concettualmente si tratta di compiti 
distinti, e in grandi progetti sono svolti da persone distinte.
Si puo' usare una OOD senza una OOP, o, in quanlche misura, una OOP 
senza una OOD, anche se i migliori risultati si hanno combinando le 
tecniche.
I "design pattern", come dice il nome stesso, appartengono alla OOD.
Si tratta di concetti in larga parte indipendenti da linguaggio di 
implementazione.
Secondo me, per essere un buon programmatore in C++ e' sufficiente 
conoscere la OOP, purche' nel gruppo ci sia anche un progettista che 
conosca la OOD.
Per buon programmatore C++ intendo uno che conosca tutto cio' che c'e' 
scritto nel libro "C++: Linguaggio, libreria standard, principi di 
programmazione" di Bjarne Stroustrup. Penso che per imparare i contenuti 
di tale libro un programmatore C esperto impieghi meno della meta' del 
tempo che impiegherebbe, diciamo, un ingegnere civile che non ha mai 
studiato la programmazione.


 EMG
Personalmente tra quelli indicati nel link che hai indicato, trovo 
questo estremamente valido e completo:
Lippman, Lajoie e Moo, "C++ Primer" 4 ed. - Addison Wesley
--
Clyde

 Conoscete un buon programma free per gestire i NG ?
Io mi trovo bene con mozilla-thunderbird.
E.

 ha scritto nel messaggio 
news:yXDGk.22713$Uo5....@tornado.fastwebnet.it...

Grazie, lo provo.
Un saluto,
Maxime. 

programmazione" di Bjarne Stroustrup.
Non basta per essere un *BUON* programmatore C*+. Se sviluppi in certi
contesti, hai bisogno assolutamente di dominare concetti di OOD.

anno non sono pazzamente entusiasti di libri in inglese, IMHO.
Be', è piuttosto vergognoso...

 Ma da conoscere per chi programma seriamente.
Non necessariamente.
Molti design pattern sono implementati all'interno di framework. Per 
usare un framework, come per esempio l'architettura document/view di 
MFC, non e' necessario conoscere nessun pattern, basta leggerne il 
tutorial o eseguirne il wizard.
Inoltre, se un progettista indica al programmatore la struttura da dare 
alle classi, poi il programmatore puo' scrivere il codice delle routine 
contenute in tali classi.


Non necessariamente.
La pensi diversamente da me. Io ritengo un BUON programmatore C++, un
programmatore che conosca ANCHE i pattern e tutta una serie di
caratteristiche del linguaggio legate alla OOP. Un programmatore che
si disinteressi di questioni architetturali solo perché i framework
che usa le inglobano già, mi sta simpatico fino a un certo punto.

 [...]
"C++ in a nutshell" Ray Lischner, O'Reilly
Lo tengo sulla scrivania da più di due anni. E' fatto bene e facile da
consultare.
Non è affatto tascabile perchè conta 780+ pagine, c'è anche la
documentazione
di tutta la libreria standard, 40 euro ben spesi.
*Non* va utilizzato per imparare il C++, per quello vai con i libri
che ti hanno
consigliato. Ti sarà molto utile nel lavoro di tutti i giorni e per
"ripassare" sugli
argomenti, una volta che li avrai compresi. E' molto utile per
trovare
rapidamente le informazioni che ti servono. Con i libri didattici, non
è sempre
facile.
Ciao, Ugo

 "C++ in a nutshell" Ray Lischner, O'Reilly
Grazie Ugo,
ho già prenotato "C++ Primer 4^ed." anche se, avrei volentieri optato 
per la versione tradotta in italiano della 3^ edizione (son pigro) ma 
sembra non sia più in catalogo. Oggi, tempo permettendo, prenoterò anche 
questo. In effetti non ho fatto riferimento ai bignami per le dimensioni 
ma per il loro contenuto 'diretto'. Hai centrato le mie esigenze.
Un saluto,
Maxime.

 implementazione.
Non sono d'accordo. Dipendono *molto* dal mondo in cui ti stai muovendo,
alcuni più di altri. Mi viene in mente il celebre discorso di Norvig a
riguardo, per dire.
-- 
-riko

 contenute in tali classi.
Uhm. Brutto mondo questo. Ma mi sono perso il pezzo in cui questo
programmatore sarebbe un "buon" programmatore. Io lo vedo più vicino ad
un compilatore "linguaggio semiformale di specifica -> C". Cioè qualcosa
di molto più vicino ad una macchina astuta che ad un "buon
programmatore".
-- 
-riko

 "C++ in a nutshell" Ray Lischner, O'Reilly
Come si confronta con il classico di Jossuttis? Io lo ho sempre sulla
scrivania e per me ha un po' la funzione che per te ha il Nutshell. 
Se conosci entrambi i testi, puoi darmi la tua opinione in merito?
Ho la scrivania e la casa piena di libri e cerco di limitarmi. :P
-- 
-riko

 Ho la scrivania e la casa piena di libri e cerco di limitarmi. :P
Ho lo stesso problema.
Ugo

 programmatore".
Per fare ancora una metafora ingegneristica, io ho detto che chi conosce 
un programma di CAD 2D impara un programma di CAD 3D piu' rapidamente di 
chi non ne conosce nessuno. Andrea Laforgia ha detto che comunque il 
tempo e' irrilevante rispetto a quello necessario a imparare 
l'ingegneria civile.
Io sostengo che il disegnatore CAD non deve necessariamente conoscere 
l'ingegneria civile, purche' nello studio ci sia anche un ingegnere 
civile che gli dice che cosa disegnare.
Vorresti sostenere che negli studi di ingegneria sarebbe bene non fare 
distinzioni tra i ruoli dei tecnici?


l'ingegneria civile.
Non farmi dire cose che non ho detto sulla base dei TUOI esempi, per
cortesia. Io non sto parlando di ingegneria civile o di CAD e ho già
detto che non condivido affatto i tuoi paralleli. Io sto parlando di C
e C++, per cortesia rispetta le parole degli altri. Non accetto il
senso lato del tuo ragionamento perché non lo condivido.
Un disegnatore CAD non è lo specchio del programmatore. Un
programmatore, per essere un BUON programmatore, DEVE conoscere certi
concetti di ingegneria del software.

 concetti di ingegneria del software.
Mi sembra chiaro a tutti che su questo punto non siamo affatto d'accordo.


 ritrovare le informazioni.
Direi "venduto"! :P
-- 
-riko