Newsgroup: it.comp.lang.c++
Titolo: Un consiglio

Ciao ragazzi , avrei intenzione ,di imparare questo linguaggio per
creare dei piccoli programmi per l'utilità del mio ufficio, potrste per
piacere indicarmi qualche libro che mi possa guidare dall'inizio in poi?
Qualcosa in italiano, che sia facilmente comprensibile, praticamente
libri per neofita :)
ve ne sarei pmolto grato!!
Vi ringrazio per la futura risposta e scusate per aver inserito un
messaggio che ha poco a che vedere con la funzionalità di questo ng, ma
visto che ne sapete più di me  a chi rivolgermi? :)
Ciao e Grazie
Mr Flysky

piacere indicarmi qualche libro che mi possa guidare dall'inizio in
poi?
Personalmente ti suggerirei caldamente "Introduzione al Visual
Basic", "Delphi spiegato al popolo", e "Java per principianti" (e mi
scusino i patiti di altri ancora fra i linguaggi ragionevolmente facili
da usare per "creare piccoli programmi d'utilita'" se non mi sono
inventato un qualche ipotetico testo per neofita nel loro linguaggio
preferito, ma mi pare che questi tre siano di gran lunga i piu'
diffusi).
In Basic, Delphi, o Java, fai fra il 90 e il 99% di quel che ti serve
(non potrai scrivere un pezzo di sistema operativo, come ad es. un
device driver, ma i programmini di utilita' li fai di sicuro!), con uno
sforzo di apprendimento fra il 10% e il 30% di quello richiesto dal
C++, e prestazioni massime fra il 50% e il 99% del C++ (a seconda
di cosa esattamente tu stia facendo, e supponendo un uso perfetto
di tutti i vari linguaggi).  Sono ottimi linguaggi, veramente potenti,
eppure ancora ragionevolmente facile da imparare e soprattutto
da usare.  C++ invece e', senza nessun compromesso, orientato
totalmente all'uso da parte di programmatori molto esperti, spesso
in grandi squadre, con esigenze di coprire il 100% dei compiti (il
99.9% non basta) con prestazioni almeno potenzialmente ottimali;
il prezzo che si paga per questo e' una complessita` enorme, ai
limiti dell'astrusita' -- il C++ e' decisamente il linguaggio di
programmazione piu' complicato attualmente in uso (secondo me
ha superato anche ADA).
Pochissimi programmatori C++ hanno veramente l'assoluta
padronanza dello strumento; e' possibile usarne un sottoinsieme,
ma considerazioni relative alle parti che uno non vorrebbe usare
continuano inesorabilmente ad emergere e "mordere" in termini
di bug praticamente incomprensibili.  Chiunque non condivida
questa opinione probabilmente non si e' mai trovato a lavorare
come "guru C++" in una software house con centinaia di ottimi
programmatori che gli sottopongono problemi come questo:
    class animal {
    public:
        animal(int);
        animal(float);
        void operator()(int);
        // ecc, ecc
    }
    //... tante, ma tante righe dopo ...:
    void mucc(double can) {
        animal x(int(can));
        x(23);
    }
"Perche' ?!?&^!@! non linka?!", ululano disperati i
programmatori (professionisti esperti e validissimi)...
quando va bene (con un po' di scalogna, linka e non
fa quel che ci si aspetta).  E "naturalmente", se uno
usa la forma alternativa ma piu' antiquata
        animal x((int)can);
che immagina equivalente, continua a incastrarsi in
certi compilatori, mentre in altri si mette a funzionare...
quando un linguaggio e' abbastanza complesso, e il
C++ decisamente *lo e'*, e' inevitabile che anche i
compilatori comincino ad avere problemi e discordie
nell'interpretare precisamente certi costrutti!
Il C++ e' *meraviglioso* per quelle cose che solo
con esso (o linguaggi di bassissimo livello, come il
C e l'assembler) puoi fare.  Ma, secondo me, se uno
esamina 100 progetti che oggi vengono fatti in C++,
e' probabile che almeno 90 di essi sarebbero di gran
lunga piu' agevoli da fare con altri linguaggi piu` facili;
se uno esamina 100 persone che stanno imparando
o usando il C++, e' probabile che almeno 90 di loro si
troverebbero molto meglio imparando e usando altri
linguaggi piu' facili.
Personalmente, pur essendo _di professione_ un guru
C++, le "piccole utility", in grande maggioranza, me le
faccio in Visual Basic, Java, perl, TCL/Tk, linguaggi di
scripting, e via facilitando... un missile balistico
intercontinentale a molteplici testate termonucleari a
rientro indipendente e' sicuramente il non plus ultra in
termini di deterrenza, ma, anche per chi ne tiene uno
da parte per ogni evenienza, un coltellino a serramanico
e' assai piu' comodo da portarsi in giro e assai piu'
pratico per la maggior parte degli usi quotidiani.
Alex

 linguaggi piu' facili.
Io attualmente sono _costretto_ a programmare in C++.  Lo trovo un
linguaggio barocco all'inverosimile e che produce eseguibili di
dimensione da circo.  Pero' se sviluppi software in una equipe di
decine e decine di persone che programmano indipendentemente e' la
migliore soluzione per trovare i bachi al piu' presto possibile - per
tutto il resto, meglio il buon vecchio C .
Ah, questa non e' una provocazione ...
-- 
Maurizio Loreti                      
http://wwwcdf.pd.infn.it/~loreti/mlo.html
Un. of Padova, Dept. of Physics - Padova, Italy          
lor...@padova.infn.it

Ah, questa non e' una provocazione ...
No, solo un'affermazione dimostrabilmente errata.
Alex

Io penso che il C++ sia un ottimo linguaggio anche se molto criptico.
Questo non giustifica, pero', chi lo utilizza nella maniera piu'
incomprensibile possibile.
Ad esempio se io scrivo "atan(1) * 4" probabilmente il 90% delle persone non
capisce cosa volevo fare anche se quello che ho scritto e' una semplice
espressione matematica (il risultato lo trovate al fondo del messaggio).
D'altronde anche tra i programmatori C c'e' chi scrive codice leggibile ed
elegante e chi lo scrive perche' nessuno ci capisca niente (... pero'
funziona!).
Ciao.
PS: Il risultato e' pi-greco.
--
Antonio Donatiello

 ......
Vero, ma penso che una delle cose più utili che un 'guru' possa fare, sia dare
indicazioni su come utilizzare il linguaggio e mettere in guardia dall'uso di 
certi costrutti. Cioè delimitare il 'sottoinsieme del linguaggio' con un insieme
di regole da seguire.
Mi pare che un ragionevole sottoinsieme del C++ dovrebbe includere l'overload
degli operatori SOLO quando effettivamente il suo uso porta inequivocabili
vantaggi rispetto all'uso di normali funzioni. Come del resto tutte le 
funzionalità 'avanzate' del linguaggio andrebbero usate con cautela e solo se 
effettivamente procurano dei vantaggi rispetto a implementazioni alternative,
in termini di chiarezza, robustezza, coerenza strutturale del codice. 
E tra le prime cose da cui un programmatore C++ dovrebbe imparare a guardarsi, 
ci sono l'insidia delle conversioni automatiche e le potenziali ambiguità dei
cast 'old style' (non per nulla sono stati introdotti i nuovi cast), tanto 
per riferirsi all'esempio da te riportato.
Con tutto ciò intendo dire che se lo sforzo principale del programmatore 
fosse quello di scrivere del codice chiaro, per quanto possibile semplice,
e ben strutturato, piuttosto che cimentarsi con le funzionalità avanzate del
linguaggio perchè 'fa figo', o magari scrivere cose a prima vista 
incomprensibili sfruttando le ben note capacità 'sintetiche' del C (fornendo 
così accoglienti nidi ai bachi sempre in agguato), sarebbe tanto di guadagnato 
per tutti. 
Se uno ha una Ferrari, non è detto che debba andare a 300 all'ora.
Se va in autostrada a 130, viaggerà più comodamente e con maggior sicurezza
che con una Panda.
Tornando al C++, so bene che non è così semplice stabilire delle regole che 
mettano al riparo (almeno nella maggior parte dei casi) da errori sottili e 
insidiosi, ma credo che in linea di massima sia preferibile muoversi nella 
direzione dell'auto-disciplina del programmatore piuttosto che indirizzarsi 
verso linguaggi auto-limitanti, anche perchè un programmatore non disciplinato
combinerà sempre dei pasticci: quello che può riuscire a fare in Visual Basic 
un programmatore 'selvaggio' potrebbe costituire la trama di un racconto 
dell'orrore...
Detto questo, a qualcuno alle prime armi forse anch'io consiglierei il Visual 
Basic e poi Delphi e Java come secondo passo, per una questione di gradualità
e di presa di contatto con differenti approcci alla programmazione. Ma per i 
professionisti del software, non avrei esitazioni a consigliare il C++.
Saluti
Paolo

dimensione da circo.  Pero' se sviluppi software in una equipe di
Sulla "dimensione da circo", vorrei notare: il Loreti mi ha
indicato in mail la URL di sorgenti C++ che secondo lui
esemplificano questo problema, sfidandomi a replicare
dopo che avessi "ottenuto un eseguibile da 28K" (la dimensione
di un equivalente programma in C).  Scaricati i sorgenti stessi
ed effettuato il minimo di porting necessario (tipo l'aggiunta di
"using namespace std;" per essere standard-compliant), ho
compilato il tutto con Visual C++ 5.0, ovviamente con opzioni
di ottimizzare per riduzione di dimensione, e ho ottenuto un
eseguibile di 8K... meno di un terzo della "dimensione di soglia"
di cui sopra.
Morale: non confondere gli eventuali difetti del _compilatore_
che uno sta usando, con difetti del _linguaggio_ che si usa.
Se per lo stesso programma C++ il compilatore che sceglie
di usare il Loreti non riesce a scendere sotto i 100Kbyte, e
un compilatore C++ fra i piu` diffusi sul mercato produce un
eseguibile di 8Kbyte, forse e' il caso di riesaminare chi debba
stare al circo -- il linguaggio C++, o chi fa certe clownesche
asserzioni su di esso senza capirne evidentemente abbastanza?-)
Alex

asserzioni su di esso senza capirne evidentemente abbastanza?-)
perfettamente d'accordo, qualche tempo fa ho scritto un device driver
per NT e ho preferito un approccio a classi usando il C++ rispetto a
quello classico in C e con un minimo di accortezza nella scrittura del
codice ne e' venuto fuori un driver di dimensioni analoghe ad altri
simili scritti in C (~20Kb) ma con una manutenzione sicuramente piu'
semplice e con un codice molto piu' facile da riutilizzare per altri
drivers.
Gianpaolo Bottin
- Live Long and Prosper -