Manuale di C++

[Ghostkonrad]

Ok, sono di nuovo OT. Ma non mi smuoverete dall'opinione che nel "Vietato leggere" manca l'expertise di programmazione che questa sezione del forum può vantare.
Allora, al momento sto seguendo un corso facoltativo di C++; anche l'acquisto di un testo da usare è facoltativo, ma io ho pensato che sarebbe comunque bene procurarsene uno. I testi giunti sino in finale sono i seguenti:



Completo e particolareggiato, consigliato a chi comincia dalle basi e vuole un testo che gli insegni progressivamente il linguaggio. Un buon compromesso tra didattica e ricchezza di contenuti (tutto ciò per sentito dire, beninteso)




Abbastanza simile al precedente, il prof non ha rintracciato grandi differenze fra i due, ma dalle recensioni di Amazon sembrerebbe ancora più didattico del precedente (a dispetto del nome).




E infine, ovviamente, lui. La bibbia. Il testo sacro. Come il Kernighan-Ritchie per il C. Ci trovi tutto, ma può risultare difficile, specie per i neofiti.


In sostanza, ho un dubbio amletico: prendere un testo con una filosofia "didattica", che funzioni come supplemento al corso, oppure lo Stroustrup, da tenere nello scaffale per referenze e consultazioni, contando solo, per i rudimenti del linguaggio, sulle slides del prof e le sessioni di laboratorio?
Per dare informazioni adeguate, ho fatto due corsi di programmazione in C (base e medio livello), in cui abbiamo svolto quasi tutti i costrutti fondamentali del linguaggio, e analizzato anche problemi di una certa complessità; me la cavo bene con il LaTeX, anche se l'ho studiato sulla celeberrima "A not so short introduction to LaTeX2", e non su un vero manuale.
Insomma, ho un'idea compiuta di cosa sia la programmazione procedurale.
Di programmazione a oggetti, però, sono del tutto a digiuno, a parte le 5 lezioni svolte sinora; in tutta sincerità, per il momento il C++ mi pare il C anarchico (), ma mi sembra di capirci bene (tuttavia non posso fare a meno di vedere una classe come una struct un po' ingrassata).
Se le slides possono essere utili per valutare il livello del corso (e quindi se valga la pena di prendere la bibbia), esse sono a questo indirizzo.

Che mi consigliate?

[cymon]

Risposta standard da forum informatico: C++ è fa sfigati, imparati Ruby

Ma questo, per fortuna, è un forum diverso.
Dunque, non conosco i testi segnalati, ma credo che il nodo principale da sciogliere sia imparare a programmare a oggetti che, se vieni dal procedurale, è un po' un casino. Imparare poi su C++ per me è anche più pericoloso che in JAVA perché la tentazione è rimanere procedurali e fare poco di più, quando invece, per fare le cose per bene, bisogna proprio cambiare filosofia.
Quindi, al di là di stare a recuperare la sintassi, che sai già e comunque può essere consultata con un rapido quick references da web, cerca il testo che più si occupi del "design" OO, piuttosto che del C++.

Che comunque rimane un linguaggio da sfigati, vuoi un manuale di Ruby*?









*Cymon è un obsoleto perlista, ma dire Ruby fa più scena

[Ghostkonrad]

Uhm, non l'avevo mai vista in questo modo, grazie.
A questo punto è probabile che lo Stroustrup sia sconsigliabile, mi sembra più orientato alla "presentazione" del linguaggio C++ in particolare, più che alla programmazione OO in generale; comunque domani in laboratorio potrò prendere visione del volume, così mi faccio un idea. Per gli altri postati, chiederò quanta attenzione dedicano alla presentazione del paradigma OO.
Vi farò sapere.

In merito al Ruby, ne sarei onorato, ma imparare più di un linguaggio la volta mi pare eccessivo ; in compenso, da quando ho visto che nel Python i blocchi di istruzioni si delimitano solo con l'indentazione, ho deciso che una tale perversione merita attenzione e studio .
Ma una cosa alla volta.

[Simbul]

In base alla mia esperienza, ti consiglierei di tenerti lontano da questi tomi omnicomprensivi rilegati in pelle umana... io ho sempre finito per usarne il 2% (pagandoli però il 100% ). Meglio qualche risorsa su Internet.

Se non ricordo male io ho usato Thinking in C++ per avere una prima infarinatura.
Occhio che, nonostante il libro sia in vendita su Amazon, è anche scaricabile llberamente: non farti ingannare

Aggiungo solo due caveat: (1) io la programmazione a oggetti la conoscevo già, quindi potrei non essere l'esempio più calzante, (2) sono quasi sicuro - ma non completamente - che il libro linkato sia effettivamente quello che ho usato

[cymon]

Messaggio inviato da Simbul

In base alla mia esperienza, ti consiglierei di tenerti lontano da questi tomi omnicomprensivi rilegati in pelle umana... io ho sempre finito per usarne il 2% (pagandoli però il 100% ). Meglio qualche risorsa su Internet.

Se non ricordo male io ho usato Thinking in C++ per avere una prima infarinatura.
Occhio che, nonostante il libro sia in vendita su Amazon, è anche scaricabile llberamente: non farti ingannare

Aggiungo solo due caveat: (1) io la programmazione a oggetti la conoscevo già, quindi potrei non essere l'esempio più calzante, (2) sono quasi sicuro - ma non completamente - che il libro linkato sia effettivamente quello che ho usato

Sicuramente ravanare in internet in cerca di un buon libro è un buon modo di procedere. Però, visto che siamo all'inizio, comunque consigliere di recuperare (online, offline, a dorso di mulo o in biblioteca) un libro libro, cioè un tomo che racconti le cose in maniera organica. Una volta fatte le basi così (io di solito non arrivo mai all'ultimo capitolo di libri del genere) ci si può buttare su internet anche in cerca di frammenti di codice.

[Ghostkonrad]

Messaggio inviato da cymon

Sicuramente ravanare in internet in cerca di un buon libro è un buon modo di procedere. Però, visto che siamo all'inizio, comunque consigliere di recuperare (online, offline, a dorso di mulo o in biblioteca) un libro libro, cioè un tomo che racconti le cose in maniera organica. Una volta fatte le basi così (io di solito non arrivo mai all'ultimo capitolo di libri del genere) ci si può buttare su internet anche in cerca di frammenti di codice.

In effetti abbiamo fatto proprio così con il C. Avevamo un libro che insegnava, in sostanza, la programmazione procedurale a partire dal C (perchè è un linguaggio usatissimo in ambito scientifico, ha grande rilevanza didattica, permette di imparare anche qualcosa sul funzionamento del calcolatore, ecc ecc...) e poi ci consigliarono di comprare un manuale nel caso volessimo buttarci sull'avanzato e avere referenze rapide per il linguaggio (nel testo principale ci si occupava soprattutto di algoritmi applicati a problemi fisici); alla fine quest'ultimo l'ho usato abbastanza di rado, giusto per qualche raffinatezza tipo i descrittori di output con numero fisso di cifre, la funzioni per operare su stringhe e similia.

Comunque, devo dire che nel primo laboratorio è stato tutto abbastanza stentato; ho voluto seguire alla lettere le pratiche di "buona programmazione" (un header file e un source file separati per ogni classe, 4 classi in tutto), e alla fine, in due ore e mezzo, ho scritto solo gli headers. I miei colleghi che non hanno voluto essere così ligi, almeno hanno scritto un programma che compilasse.

Comunque, tornando al testo (in merito a ciò condivido quanto detto da Cymon), credo proprio che lo Stroustrup sia escluso. A questo punto rimangono gli altri due e quello fornito da Simbul.

[cymon]

Messaggio inviato da Ghostkonrad

In effetti abbiamo fatto proprio così con il C. Avevamo un libro che insegnava, in sostanza, la programmazione procedurale a partire dal C (perchè è un linguaggio usatissimo in ambito scientifico, ha grande rilevanza didattica, permette di imparare anche qualcosa sul funzionamento del calcolatore, ecc ecc...)

Il C si impara perchè il C è il C. Non ci sono scuse. Dal C non si scappa. Devi almeno far finta di saperlo usare una volta che lavori nell'informatica (io )

Messaggio inviato da Ghostkonrad

Comunque, devo dire che nel primo laboratorio è stato tutto abbastanza stentato; ho voluto seguire alla lettere le pratiche di "buona programmazione" (un header file e un source file separati per ogni classe, 4 classi in tutto), e alla fine, in due ore e mezzo, ho scritto solo gli headers. I miei colleghi che non hanno voluto essere così ligi, almeno hanno scritto un programma che compilasse.

Tendenzialmente la tua è la buona pratica. Ragionare solo sugli headers in astratto significa progettare più che programmare che è la cosa difficile. Fare un if then e due while sono buoni tutti. Il problema è che molta gente tiene più al compilare che alla buona programmazione motivo per cui ci sono in giro cose raccapriccianti. Vai avanti così

[Ghostkonrad]

Messaggio inviato da cymon

Tendenzialmente la tua è la buona pratica. Ragionare solo sugli headers in astratto significa progettare più che programmare che è la cosa difficile. Fare un if then e due while sono buoni tutti. Il problema è che molta gente tiene più al compilare che alla buona programmazione motivo per cui ci sono in giro cose raccapriccianti. Vai avanti così

Naturalmente, una discussione nerd sulla buona programmazione sarebbe priva di un cuore, senza una striscia di xkcd sul tema:

[Ghostkonrad]

Ridiggo fuori questo topic per una piccola questione che mi attanaglia in questi giorni.
Mi è stato insegnato che, quando si fa l'overload di un operatore (ma vale anche per le funzioni in genere), sia sempre meglio restituire i risultati "by reference", e non "by value" dato che questo comporta risparmio di tempo macchina e memoria; ovviamente quando ciò è lecito.
Ad esempo la dichiarazione di un operator= (incapsulato in una classe foo) la scriverei così:

const foo& operator=(const foo& rhs);

La referenza restituta è const per evitare che un programmatore che utilizzi la classe (e che ovviamente viene supposto come la persona più idiota e incapace del pianeta) possa scrivere orrori del tipo:

(foo1=foo2)=foo3;

Allora però verrebbe da obiettare: la riga sopra fa effettivamente sanguinare gli occhi, ma di fatto, se provo a farlo con tipi di sistema, il programma compilerà, mentre il const messo sopra impedirebbe brutalmente ad esso di compilare.
Se a filosofia del C++ è che le mie classi sono allo stesso livello dei tipi di sistema, perchè non mi dovrebe essere permesso di fare questo?
Giusto per capire se è una questione ben risolta, o se la pratica invece varii da programmatore a programmatore.

[cymon]

Messaggio inviato da Ghostkonrad

Ridiggo fuori questo topic per una piccola questione che mi attanaglia in questi giorni.
Mi è stato insegnato che, quando si fa l'overload di un operatore (ma vale anche per le funzioni in genere), sia sempre meglio restituire i risultati "by reference", e non "by value" dato che questo comporta risparmio di tempo macchina e memoria; ovviamente quando ciò è lecito.

Ghost, l'overload degli operatori è riconosciuto da tutti come un'attività peccaminosa, un po' quello che pensa il tuo parroco del fatto che ti chiudi in bagno con le immagini di CC (spacciandole per manuali di C++, ovviamente).
Uno degli strumenti più potenti e versatili della programmazione moderna, ma anche tra i più pericolosi.

Questo perché tu lo sappia, per il resto non ho capito un'acca di quello che dici. Io sono un bravo bambino e queste porcherie non le ho mai trattate.

[Ghostkonrad]

Messaggio inviato da cymon

un po' quello che pensa il tuo parroco del fatto che ti chiudi in bagno con le immagini di CC (spacciandole per manuali di C++, ovviamente).

Diavolo, per un attimo ho flashato Steve Jobs che mostra il nuovo logo dell'objective C con C.C. come sponsor.
Pizza Hut diventerebbe il fornitore di cibo ufficiale degli Apple Users.

Strano comunque, fare l'overload degli operatori viene ritenuta una delle abilità che chi esce dal corso deve imprescindibilmente possedere, tanto è vero che quest'anno è stato trattato già alla seconda lezione.

[[FTR]Lo-Rez]

Una discussione su C++, naturalmente, non è completa senza le C++ Frequently Questioned Answers... in cui ogni singola minima caratteristica di questo linguaggio viene criticata senza pietà con argomenti che suonano molto convincenti. Tanto per farti passare la voglia di impararlo.

[[FTR]Lo-Rez]

Messaggio inviato da Ghostkonrad

Strano comunque, fare l'overload degli operatori viene ritenuta una delle abilità che chi esce dal corso deve imprescindibilmente possedere, tanto è vero che quest'anno è stato trattato già alla seconda lezione.

Questo è curioso perché l'overload degli operatori è visto da molti come IL MALE, tanto è vero che l'hanno completamente lasciato fuori da Java, ad esempio.
Si dice in giro che usare i cari vecchi operatori per fargli fare cose pervertite renda il codice molto difficile da leggere e da manutenere.
Non per niente Perl incoraggia l'uso abbondante dell'overloading degli operatori, e anzi ci infila pure l'overloading delle VARIABILI, e perfino delle COSTANTI!!1!
Se vuoi in perl puoi fare l'overloading pure di tua sorella... senza motivi particolari, solo per il gusto di piegare il linguaggio al tuo volere. Proprio l'esatto opposto della filosofia di Java, che considera tutti i programmatori come dei bimbi piccoli.
Il C++ non ha una filosofia, è solo grosso e cattivo e puoi farci di tutto e di più, quindi bisognava metterci anche l'overloading degli operatori, sennò non era abbastanza "potente".

Naturalmente FQA ne ha anche per lui.

[cymon]

Messaggio inviato da [FTR]Lo-Rez

Se vuoi in perl puoi fare l'overloading pure di tua sorella... senza motivi particolari, solo per il gusto di piegare il linguaggio al tuo volere. Proprio l'esatto opposto della filosofia di Java, che considera tutti i programmatori come dei bimbi piccoli.

"I rischi connessi ad un abuso dell'overloading, sono però ampiamente compensati dai benefici che ne possono derivare nelle mani di un programmatore [perl] avveduto. Il linguaggio Java non tiene conto di questo perché, come è noto, fa delle assunzioni piuttosto offensive sulle capacità di chi se ne serve."

Scritto qui via Perl.it - Il punto di riferimento del linguaggio Perl in Italia

[Ghostkonrad]

In C++ fondamentalmente si suppone che il programmatore che utilizzerà le tue classi sia un bimbo piccolo; o almeno così mi hanno insegnato.

Se non sbaglio alla magistrale c'è anche un corso dove si insegna il Perl, ma alla fine il C la fa da padrone per i motivi succitati, e il C++ perchè è il linguaggio con cui viene sviluppato il software per tutti i grandi esperimenti scientifici moderni in fisica, in particolare fisica della particelle, dove se ne fa un largo uso (ad esempio al CERN).

[[FTR]Lo-Rez]

Messaggio inviato da Ghostkonrad

In C++ fondamentalmente si suppone che il programmatore che utilizzerà le tue classi sia un bimbo piccolo; o almeno così mi hanno insegnato.

Secondo me ti hanno insegnato una mostruosità colossale.
Un conto è essere tolleranti negli input e rigorosi negli output di quello che si fa, che è la buona regola di tutta l'Ingegneria (e in particolare della Vita).
Un'altra cosa è scrivere 300 righe di codice inevitabilmente pieno di bug per fare l'overloading del + supponendo che chi userà le tue classi sia troppo idiota per comprendere .add(). Che poi, CHI userà mai le tue classi? Se non sbaglio voialtri siete scienziati, casomai siete VOI gli utenti.

[cymon]

Messaggio inviato da [FTR]Lo-Rez

Secondo me ti hanno insegnato una mostruosità colossale.
Un conto è essere tolleranti negli input e rigorosi negli output di quello che si fa, che è la buona regola di tutta l'Ingegneria (e in particolare della Vita).

Notare come la VIta sia sottinsieme dell'ingegneria

Messaggio inviato da [FTR]Lo-Rez

Se non sbaglio voialtri siete scienziati, casomai siete VOI gli utenti.

Quindi assolutamente inabili a produrre qualsiasi tipo di codice, come tutti gli utenti.

[Ghostkonrad]

In realtà dipende, se fai il teorico è molto probabile che scriverai programmi solo a tuo esclusivo uso e consumo, quindi si può anche tralasciare qualche pratica purista di buona programmazione (tipo "mai variabili globali"); se lavori in un gruppo sperimentale di 10 o più persone, sul tuo codice ci metteranno le mani anche tutti gli altri, e useranno le tue classi per ereditare da esse, scrivere nuove applicazioni, e tutto il solito Jazz.
Si suppone che debbano essere in grado di fare ciò senza neanche avere sottomano il source (solo con l'header e l'interfaccia), e quindi bisogna scrivere classi il più chiare e auto-esplicative possibile.
Al CERN hanno ancora pezzi di codice in Fortran che stanno là dagli anni '80 e prima, tanto per dare l'idea.

[cymon]

Messaggio inviato da Ghostkonrad

Si suppone che debbano essere in grado di fare ciò senza neanche avere sottomano il source (solo con l'header e l'interfaccia), e quindi bisogna scrivere classi il più chiare e auto-esplicative possibile.

E' ovviamente più complicato di così. Diciamo pure che tutto il mondo dell'informatica ci prova e non ci è tutt'oggi riuscita. Certi discorsi sulla trasparenza, l'uso della semplice interfaccia e menate del genere sono la base di tutti i libri di testo dell'informatica e si scontrano con un mondo del lavoro che funziona esattamente all'incontrario.
Autoesplicativo, spesso, è solo sinonimo di "non ho voglia di scrivere documentazione" o "non ho voglia di leggere documentazione"

Messaggio inviato da Ghostkonrad

Al CERN hanno ancora pezzi di codice in Fortran che stanno là dagli anni '80 e prima, tanto per dare l'idea.

Il mondo bancario va tutt'oggi avanti col COBOL, quindi non c'è niente di cui stupirsi.

[Ghostkonrad]

Ri-ri uppo il topic per un'ultima questione (stavolta davvero l'ultima), dopodiche potremo lasciarlo ad avvizzire nei remoti fondi della sezione.
Mi accingo finalmente a sostenere il tanto agognato esame, tutto quel che ho da fare è finire il programmozzo su misura che il prof mi ha assegnato (siamo già a sei classi ) e poi presentarglielo con dettagli sulle scelte e sul design adottati. In teoria non è previsto che tale presentazione sia accompagnata da un class diagram in UML, ma di certo farne uno può aiutare a spuntare una più bella figura.
Quindi quello che chiedo è se qualcuno mi può suggerire un software (ovviamente gratuito) per il disegno di questi diagrammi.