Newsgroup: it.comp.lang.c++
Titolo: apprendimento C++

salve,
la domanda che vorrei porvi è la seguente: quelli di voi
particolarmente cazzuti, sia nella conoscenza del C++ che nella
progettazione OO, come hanno imparato? Vi hanno insegnato tutto
all'università (informatica - ing. informatica), oppure vi siete
formati autonomamente utilizzando magari le basi scolastiche? Oppure
ancora sul posto di lavoro? Mi piacerebbe che qualcuno scrivesse
qualcosa sull'argomento.
Io per esempio sono diplomato come perito informatico e domani (si
spera :-)) avrò anche il diploma in ing. informatica, e devo dire che
nell'apprendimento di queste cose sono piuttosto veloce, anche se
soffro tuttora di una mentalità orientata più alle procedure che non
agli oggetti (causa Pascal e C, suppongo), ma resta il fatto che buona
parte di quello che vedo e leggo non lo conosco (e infatti questo NG
mi è strautile e spero che resista agli OT e resti com'è). Cosa ne
pensate?

 pensate?
Che ti conviene cominciare a leggere qualche libro per conto tuo. Sui
principi generali dell'Orientamento ad Oggetti credo che il riferimento
migliore resti:
G. Booch, "Object Oriented Analysis & Design with Applications" ed.,
Addison Wesley.
Per il C++ non si puo' esimere da:
B. Stroustrup, "The C++ Programming Language" 3 ed. (o ancora meglio la
special edition), Addison Wesley.
Ciao,
Nicola

special edition), Addison Wesley.
Special Edition???
Luc.

 Special Edition???
E' un'edizione riveduta e aggiornata, che contiene un paio di documenti
che erano disponibili solo su Web. E' anche, gasp!, rilegata...
Ciao,
Nicola


ti ringrazio x la tua opinione, sono assolutamente d'accordo che non
ci si puň permettere di fermare i propri studi, in questo ambiente, e
la lettura di altri testi era senz'altro una mia prerogativa.
Pregherei anche gli altri di dare una propria opinione, non fate i
modesti, di 'cazzuti' ce n'č piů di uno qua ;-)

pensate?
Non credo che la laurea fornisca la "bacchetta magica"...
come non credo che il trucco consista nell'ingegnerizzazione
del processo di produzione software.
Secondo me la scrittura di software e' molto piu' simile
al lavoro di un artigiano che a quello di un reparto di
produzione industriale ... e solo l'esperienza e la scrittura
di milioni di linee di codice cercando di migliorarle e di
apprendere in continuazione porta a buoni risultati.
Chi cerca a mio parere "il trucco", il "sistema che risolve"
ha secondo me perso in partenza... perche' il trucco non c'e'.
Della formazione universitaria ho apprezzato molto il rigore
(che l'ITIS non mi aveva insegnato) e il dover mettere tutti
i puntini sulle i. Questo e' un atteggiamento mentale che
per un programmatore e' secondo me fondamentale.
Inoltre matematica e' una scienza che "costruisce" e anche
questo penso che sia l'approccio giusto alla programmazione...
in altre parole come posso spiegare il significato di una
equazione differenziale giustificando quello che dico sino
ai numeri naturali (anche se oggi commetterei sicuramente
qualche errore) secondo me un programmatore dovrebbe riuscire
a giustificare dentro di se cosa sta succedendo dalla chiamata
del distruttore sino alla CPU (con qualche infarinatura di
cosa succede dopo ... andando verso il metallo).
Personalmente non penso che "Object Oriented" sia un sistema
per evitare la conoscenza... ma sia invece un (ottimo) sistema
per organizzarla. Non credo che si possa costruire molto senza
capire...
Di sicuro non si va lontano con un linguaggio come il C++ in
cui se non si capisce cosa succede (o non si mandano a
memoria in alternativa un miliardo di regole astruse) prima o
poi si va a sbattere contro un muro e ci si fa malissimo.
Il nostro e' un campo in cui non si smette mai di studiare...
io studio da circa 20 anni su computer e ancora mi sembra di
non sapere nulla
(sara' mica che sono tonto ? hehehe)
Io ti consiglierei di proseguire con gli studi formali... il
rigore universitario aiuta (anche se a ingegneria non so se
si segua lo stesso approccio di matematica... in fondo e'
una scienza diversa). Quello che conta realmente secondo me
e' pero' l'esperienza concreta e soprattutto cerca di
resistere alla tentazione di pensare di aver capito tutto...
e' solo una sensazione che rende impermeabili e nel nostro
mondo chi non impara (in continuazione) muore.
Ho visto amici (anche molto intelligenti) finire secondo me
male per essersi infilati sotto quello scudo.
HTH
Andrea
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff

 male per essersi infilati sotto quello scudo.
su questo non ci sono dubbi, io penso continuamente di non avere
capito niente dalla vita, dall'università e che se vado a fare il
pizzaiolo forse mi risparmio un mucchio di mal di testa. A parte
questo, ovviamente neanch'io so se l'approccio di ingegneria è uguale
a quello di matematica: io personalmente credo di avere imparato più
che il formalismo la capacità di apprendere rapidamente concetti.
Quello che mi piacerebbe poter dire è che anche l'OOP lo comprendo
rapidamente, ma purtroppo non è così. Leggo e rileggo articoli a
destra e manca e mi sembra di aver capito tutto, riesco anche a
risolvere dei problemi di progettazione se sono dei casi teorici, ma
poi arrivo a scrivere il mio bel programma win32 ad eventi e non
riesco a venirne a capo. A questo punto non riesco a capire se sono
gonzo io o se effettivamente la programmazione ad eventi non si
adatta molto bene ad una modellazione ad oggetti. Tu/voi di questo
cosa ne pensi/pensate?

O forse e' win32 che e' tutto un pasticcio... :-)
Ciao,
Nicola

 wrote in message
3A2779B5...@divalsim.it...


cosa ne pensi/pensate?
Io credo che la programmazione ad eventi sia contrapposta
alla programmazione con controllo esplicito di flusso (quella
che si rappresenta bene con i flow chart). In un programma
ad eventi lo stato e' definito da un grande numero di
variabili e le variazioni di stato non seguono uno schema
prefissato. Una programmazione ad eventi a mio parere si
accompagna perfettamente con un approccio object oriented in
cui lo stato viene rappresentato in un insieme di unita'
logiche con un certo grado di autonomia (le classi) che
permettono di suddividere bene un problema in sottoproblemi.
Le Win32 API sono pero' state pensate per il linguaggio C
e in alcuni punti sono secondo me lontane da un approccio
object oriented.


 permettono di suddividere bene un problema in sottoproblemi.
 
Mi permetto di sollevare un obiezione. Un problema della programmazione ad 
oggetti e' quando una classe si deve riferire ad un'altra.
Esempio classico: abbiamo un controllo "listbox" ed un "button". Il bottone 
se premuto pulisce la lista.
Per cui un evento di 'bottone' si deve trasformare in un metodo di lista.
L'approccio classico prevede una definizione della classe bottone ed una 
sua derivazione che incorpori la "specializzazione":
        se si verifica l'evento "pushbutton" allora richiama il metodo
        lista.clear
notare che cosi l'oggetto button deve conoscere l'esistenza di un 
puntatore/reference dell'oggetto lista ( notare la contrapposione di una 
definizione con una istanza )
Cosi funziona il delphi ( e quindi benso anche il CBuilder ) ed il VB ( 
anche se non e' definibile linguaggio OO )
Una libreria abbastanza diffusa sotto Linux e disponibile anche sotto 
Windows ( le QT ) ha affrontato il problema in una maniera interessante. Ha 
esteso il concetto di classe con altri due "tipi"; la classe normalmente 
incorpora metodi e membri; sotto le QT ( che e' una libreria C++ ) vengono 
implmentati anche 'signal' e 'slot'.
Il collegamento fra classi e' realizzato colleganto un signal di una classe 
con uno slot di un'altra; poi quando necessario verra lanciato un signal ( 
a cui corrisponde alla fine la chiamata del metodo opportuno )
// lato button, lancio dell'evento
emit clicked(<eventuali-paramtri>);
// latolista
slot: clear( <eventuali-parametri> ){
}
Ora non si deve specializzare piu' la classe bottone, ne tanto meno questa 
deve conoscere chi referenzia la classelista.
E' compito poi di un "entita superiore" ( la funzione in cui vengono 
istanziati gli oggetti per esempio ) collegare il signal clicked di bottone 
con lo slot "clear()" di lista con una istruzione del tipo:
QObject::connect( &button, SIGNAL(clicked()), &lista, SLOT(clear()) );
Tecnicamente viene realizzato con un sorta di preprocessore che maschera le 
varie definizione di slot/signal, ed i collegamenti trasformando il tutto 
in codice C++ "puro"; i signal non sono altro che puntatori a funzione, e 
gli slot sono funzioni; ci sono pero' feature interessanti del tipo: 
un slot puo' essere collegato a piu' signal e viceversa
nel momento in cui un oggetto e distrutto, si risolve il collegamento. 
Sempre sotto linux c'e' un'altra libreria che implementa un comportamento 
del genere senza preprocessore "custom" ma facendo un massiccio uso di 
template
Mi sembra un approccio interessante, vorrei la vostra opinione in merito.

Dipende da quante possibilita' hai di passare ad un sitema operativo
serio :-)
Ciao,
Nicola

Mi sembra un approccio interessante, vorrei la vostra opinione in merito.
Io trovo l'approccio publisher/subscriber sicuramente
interessante... non vedo pero' come questo contrasti con
il mio posting sulla semplificazione della programmazione
ad eventi in un ambiente a oggetti.
Io dicevo semplicemente che in programma OO lo stato viene
suddiviso in stati di sotto-unita' in modo pulito... ovvero
lo stato del bottone, lo stato del listbox etc. etc.
Questa suddivisione mi sembra semplifichi notevolmente il
disegno quando si lavora ad eventi ovvero senza il concetto
di flusso esplicito ma come automa a stati.


 nel momento in cui un oggetto e distrutto, si risolve il collegamento.
Non conosco abbastanza QT per esprimere un'opinione seria: di primo
acchito mi pare che si sarebbe potuto ottenere risultati simili con un
approccio piu' pulito.
 
Ciao,
Nicola

template
mi puoi dare un link?
già che ci sono, avete dei link a dei pattern per un gestire le
finestre in una GUI?
Anto

 ad eventi in un ambiente a oggetti.
[...]
In effetti mi sono espresso male; quando ho detto "sollevo un obiezioni" 
non intendevo certo dire che con la OO si e' tornati indietro; e che si 
potrebbe fare meglio; quello che ho portato come esempio ( le QT ) mi 
*sembra* un passo in avanti. Ho voluto postare questa mia "esperienza" per 
farla conoscere a chi non la conosce e essere informato di eventuiali altri 
ancora approcci.
Per esempio non sapevo di Java; ora vado a cercare maggiori info.

 finestre in una GUI?
la libreria si chiama 
libsigc++ ; cercala su freshmeat 
http://www.freshmeat.net
.