Newsgroup: it.comp.lang.c++
Titolo: inizio studio C++

Salve, vorrei chiedervi una cosuccia.
Ho iniziato a studiare lo C++ da zero da autodidatta, acquistando un
libro della Apogeo in una libreria universitaria della mia città, vi
confesso che non ho mai programmato sino ad ora e ne tantomeno
frequento l'università dove si studia lo C++. Si puo' diventare bravi
coder senza aver studiato una riga di codice all'università.
Sono curioso di sapere se i programmatori di videogiochi in C++ hanno
incominciato da autodidatta come il sottoscritto?
P.S.
Non conosco nessuna riga di codice Turbo Pascal, Visual Basic,
Ecc....Ho iniziato direttamente lo studio C++ dal 2003.
Saluti

 incominciato da autodidatta come il sottoscritto?
Di sicuro alcuni si.
 
Ciao,
Nicola

 Saluti
Anch'io ho iniziato come te: da zero da autodidatta (senza
conoscere altri linguaggi). 
Non sono un programmatore professionista, svolgo un'altra 
professione e per me il c++ è un hobby. Comunque penso che 
molto dipenda da quanto tempo tu dedichi allo studio e alla 
pratica della programmazione.
Ciao.
Sergio
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Ecc....Ho iniziato direttamente lo studio C++ dal 2003.
non per scoraggiarti, ma hai iniziato dal linguaggio di programmazione
meno adatto ai principianti. IMHO e` dura, poi dipende dal tuo impegno +
le capacita` che possiedi.
Saluti
-- 
[ cikko <cikkox (on) yahoo . it>    ]
[ 
http://cikkox.altervista.org
      ]
[ GNU/Linux Registered User #365929 ]
[ GnuPG/OpenPGP key available       ]

 le capacita` che possiedi.
Paradossalmente però per "capire" la "buona" programmazione probabilmente il 
C e l'ASM (e in seconda istanza il C++) sono i linguaggi migliori. Finchè 
non ti scontri con la dura realtà di come funzionano le stringhe non capirai 
mai perchè con le stringhe bisogna starci attenti... E finchè non ti scontri 
con la dura realtà dell'allocazione della memoria non capirai mai i pregi e 
i difetti dei vari tipi di costrutti come array, liste ecc.
La programmazione in fin dei conti è soprattutto genio/arte + algoritmi :-)
--- bye 

 La programmazione in fin dei conti è soprattutto genio/arte + algoritmi :-)
quote...


 
Ciao,
-- 
Matteo Settenvini
FSF Associated Member
Email : 
mat...@member.fsf.org
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d--(-) s+:- a-- C++ UL+++
P?>++ L+++>$ E+>+++ W+++ N++ o?
w--- O- M++ PS++ PE- Y+>++
PGP+++ t+ 5 X- R tv-- b+++ DI+
D++ G++ e h+ r-- y?
------END GEEK CODE BLOCK------

 C e l'ASM (e in seconda istanza il C++) [...]
Strano come dissenta anche zio Bjarne:
http://www.research.att.com/~bs/new_learning.pdf
Ed io sono d'accordo con Stroustrup.
Lo studio di C e ASM prima della programmazione a oggetti, per quanto ho
potuto vedere, crea più confusione di quanta ne risolve a chi poi deve
comunque transitare dai primi al secondo.
Meglio partire subito con una mentalità OOP e con C++. Poi se mi dite
che roba tipo Java nasconde veramente troppa complessità al
programmatore, in quel caso do ragione a MaxMax.


 perdita di tempo per un qualsiasi progetto...
Infatti mica ci devi programmare con l'Assembly :-) Lo usi per capire come 
funzionano le cose... Lo usi per capire che ci sono delle priorità: devi 
minimizzare il numero di variabili usate ma (più importante) devi 
minimizzare il numero di chiamate a funzione. E se possibile (ma con 
priorità minore) devi minimizzare le moltiplicazioni e, se possibile, devi 
fare moltiplicazioni per potenze del due. E se proprio non devi non usare 
float e double. Poi devi imparare a temperare queste cose con la leggibilità 
del codice :-)
--- bye 

Il problema di programmare direttamente in c++ è che una programmazione 
"estrema" in c++ può assomigliare molto a una programmazione in Visual Basic 
(da un punto di vista della velocità). Uno dei problemi in effetti che avevo 
letto dell'overloading degli operatori è che nascondono al programmatore il 
peso dell'operazione. Uno parte dal presupposto che un = o un + siano 
operazioni "veloci". Ma quando in una classe un operatore è nascosto non lo 
puoi sapere. Un esempio classico potrebbe essere quello delle string. Se 
sono reference counted allora farne copie è un'operazione velocissima (direi 
istantanea) ma se non lo sono allora copiarle è un'operazione da minimizzare 
assolutamente. Ecco... Un C++ "estremo" nasconde tutto ciò 
all'implementatore. In C non ti saresti mai chiesto "quanto tempo perderò a 
copiare questa stringa" perchè lo puoi misurare (dopotutto se tu non fai 
strcpy la stringa mica si muove da dove sta)
Ignorando poi i problemi dei "contenitori" STL (liste ecc) che funzionano 
benissimo per dati primitivi ma meno bene per contenere classi "complesse".
Io non credo che un'introduzione all'informatica attraverso un minimo di C e 
ASM possa rovinare così tanto un programmatore da non permettergli di 
imparare la programmazione OO. Invece credo sia vero il contrario: se tu hai 
imparato a usare le string, sei disposto ad abbandonarle solo perchè non sai 
esattamente quanto siano "pesanti"?
Poi esistono dei costrutti che sono difficili da usare e basta... io non 
sono mai riuscito a usare il try/catch per esempio... Ma questo è 
probabilmente legato al fatto che lavorando in Windows (che non usa di suo 
le eccezioni) dovrei creare wrappers per tutto... 

Salve a tutti e grazie per le vostre risposte.
Volevo chiedervi un ultima cosuccia:
Perchè parlate di complessità al riguardo delle stringhe, degli array
ecc... in C++ ?
Distinti saluti

ecc... in C++ ?
Allora...
int a = 5;
int b = a;
int c = a + b;
Tu guardando questo codice hai un'idea immediata della complessità delle 
operazioni. Sai che lavorare con gli interi è veloce e le somme su interi 
sono velocissime. (disclaimer: stiamo parlando di architetture "standard". 
Normali PC o Mac. Che nessuno mi tiri fuori che sui processori dedicati 
fatti per certe operazioni gli interi sono lenti)
Ora invece prendiamo le string delle STL. La string è una classe molto buona 
adatta a lavorare con le stringhe. Le puoi usare in maniera "naturale" 
(naturale per gente che viene da un mondo fuori-c). Le puoi usare come se 
fossero interi.
string a = "Pippo";
string b = " pluto";
string c = a + b;
string d = a;
Ora... Guardiamo questo pezzo di codice senza saperne molto su come è 
implementata la classe string. La domanda che io mi pongo è: quanto "tempo 
macchina" occuperanno questi comandi? A occhio e croce tu non lo vuoi sapere 
:-)
E' probabile che, traducendo il tutto in C, un'implementazione "standard" 
(che non sia reference counted) realizzerà qualcosa del tipo :
// string a = "Pippo";
size_t aLen = strlen("Pippo");
char *a = (char*)malloc(aLen);
// string b = " pluto";
size_t bLen = strlen(" pluto");
char *b = (char*)malloc(bLen);
// a + b;
size_t tempLen = aLen+bLen;
char *temp = (char*)malloc(aLen + bLen);
strcpy(temp, a);
strcpy(temp+aLen, b);
// string c = (a+b)
size_t cLen = tempLen;
char *c = (char*)malloc(tempLen);
strcpy(c, temp);
// string d = a;
size_t dLen = aLen;
char *d = (char*)malloc(aLen);
d = strcpy(d, a);
E' vero... avrei dovuto usare new invece che malloc... ma tanto su parecchi 
compilatori la new è una malloc type safe che richiama il costruttore :-)
E' probabile che l'ottimizzatore del compilatore, usando una cosa che si 
chiama lvalue optimization, farà saltare tutta la parte della tempstring. 
Però è un'ottimizzazione. Non credo sia OBBLIGATO a farla. Io (purtroppo) 
faccio parte della squola (con la q) di pensiero che la prima ottimizzazione 
la deve fare il programmatore.
Cmq vedi come 4 semplici righe di C++ siano diventate tante più righe di C? 
Non è facile valutare la complessità di una riga di C++. Invece guardando le 
righe di C (che sono abbastanza illegibili) tu capisci subito la loro 
complessità.

 
strcpy(a,"Pippo");
Non  mazzuolarmi :-) e' che cerco di vedere ogni cosa come spunto per 
esercizio ;-)
Fab

 esercizio ;-)
Vero... Per la fretta mi sono dimenticato DUE strcpy (anche per pluto)
--- bye 

 complessit�.
tipo guardando una riga che invoca una select()? o una funzione di una
libreria che ha scritto lo zio Pino?
comunque ho capito il tuo punto di vista e ti do ragione. è una delle
ragioni per la quale il C è molto più gettonato del C++ per scrivere, ad
esempio, sistemi operativi.
tuttavia, a meno di non dover scrivere compilatori, sistemi operativi o
similia, imparare prima il C++ _studiandolo come C++_ (e magari dopo il
C?) ti permette di capire a fondo la filosofia OOP e poi di approdare
alla procedurale più semplice, con molta meno probabilità di fare errori
difficili da correggere e comprendere.
studiare il C++ avendo in mente il C è spesso fuorviante.


 
Io credo che sia sbagliato considerare il C++ come se fosse una seconda 
versione del C e comportarsi di conseguenza, ma conoscere il C non da 
problemi a imparare il C++ se si studia veramente e si sa quello che si 
fa. Io ho imparato prima il C e sto ancora studiando il C++, ma non sto 
avendo problemi a capire la programmazione OO. Almeno questo e' quello 
che mi sembra per ora.. :-)
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d--(-) s+:- a-- C++ UL+++
P?>++ L+++>$ E+>+++ W+++ N++ o?
w--- O- M++ PS++ PE- Y+>++
PGP+++ t+ 5 X- R tv-- b+++ DI+
D++ G++ e h+ r-- y?
------END GEEK CODE BLOCK------
Di cosa si tratta? Mi ricorda vagamente il brainfuck..
-- 
Devaraja (Xdevaraja87^gmail^c0mX)
Linux Registerd User #338167
http://counter.li.org

asintoticamente, se non la supera.
Secondo molti benchmark anche Java tende asintoticamente se non supera il C 
:-)
In effeti cmq il problema di fondo non è il C++ come linguaggio piuttosto il 
C++ come librerie STL. Il C++ senza considerare le librerie STL è 
prevedibile. Il funzionamento "tipico" di classi, polimorfismo e funzioni 
virtuali è "noto" (nel senso che esistono alcune implementazioni diverse ma 
alla fin fine tu sai che saranno solo un minimo più lente di una chiamata 
diretta a funzione). Nella stessa maniera in cui una mersona non si mette a 
fare copie di struct da 80 bytes in C non si mette a fare copie di classi in 
C++ e cerca sempre di passarle per riferimento in giro. Il problema è che il 
"buon" C++ è molto spesso considerato essere C++ (inteso come compilatore) + 
STL come se le STL fossero la panacea di ogni male. Al contrario le STL, 
essendo molto "generiche" (e forse e soprattutto essendo il risultato di 
un'opera che talvolta è stata più burocratica che ingegneristica, vedi per 
esempio "oh... le stringhe non possono più essere reference counted perchè 
teoricamente si potrebbe, ma a causa di una delle regole che devono seguire 
non si può") non sono il martello unico da usare ("se tutto ciò che hai è un 
martello ogni problema di sembrerà un chiodo")
--- bye 

 i difetti dei vari tipi di costrutti come array, liste ecc.
Eppure i pregi e i difetti delle diverse strutture dati li conoscono
anche quelli che programmano in Lisp o in Python. Chissa' come mai...
Ciao,
Nicola


Come volevasi dimostrare.
Ciao,
Nicola

Ciao,
credo che non si possa dire in generale cosa sia migliore di cosa, ad 
esempio per fare motori grafici bisogna tanto conoscere (o meglio, 
maneggiare con coerenza) le tecniche di astrazione giuste nel contesto 
del problema sia il funzionamento a basso livello della macchina (o 
macchine, in certi casi) su cui il programma deve girare,magari essendo 
maniaci e pesando ogni operazione che si andra' a fare.
Che poi sia migliore il C oppure l'Assembler per comprendere il 
funzionamento di un hardware non saprei, molto spesso e' soggettivo 
(magari qualcuno monetizza molto piu' con Simulink in Matlab :) ), 
sicuramente permettono un'interazione migliore con le parti 'atomiche' 
della macchina con cui si pu' avere a che fare piu' da 'vicino'.
In generale, sarebbe bene essere almeno ad un punto medio tra le due cose.
IMHO ovviamente
Nicola Musatti ha scritto:


 Ma questo è probabilmente legato al fatto che lavorando in Windows (che non usa di suo le eccezioni) dovrei creare wrappers per tutto...
Questa mi e' nuova.
Faresti meglio a documentarti prima di scrivere cose incomplete o
inesatte. Puoi cominciare qui:
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1666.pdf
Ciao,
Nicola

 Questa mi e' nuova.
Beh... vediamo... Le API del Windows non hanno eccezioni. Le MFC neanche. Le 
ATL neppure. Le ATL/WTL idem. Le QT non ne parliamo. Le GTK (con la libreria 
per C++ gtkmm) no (e anzi nella faq ti dicono di starci attento). Quindi 
dove lo trovo il supporto alle eccezioni?
--- bye 


Perche' ci si focalizza erroneamente prima sulle presunte prestazioni
del codice che non sulla sua correttezza o sulla sua manutenibilita'.
In realta' sarebbe opportuno concentrarsi sullo scrivere codice chiaro
e corretto e poi, a fronte di una misura oggettiva, rivedere quelle
parti che causano problemi dal punto di vista prestazionale.
Ciao,
Nicola

 complessità.
Non e' vero. Per conoscere *veramente* la complessita' del codice C qui
sopra devi conoscere la complessita' di:
strlen
malloc
strcpy
Mentre per capire il codice C++ piu' sopra devi conoscere:
string::string(const char *)
string::string(const string &)
string::operator+(const string &)
Con la differenza che, come tu stesso ammetti, il C e' meno
comprensibile. Il vero problema e' che conosci il C meglio del C++.
Ciao,
Nicola


La tua posizione diventa sempre meno difendibile :-)
Ciao,
Nicola

 martello ogni problema di sembrerà un chiodo")
In questo messaggio non spieghi quale ritieni essere il problema
dell'STL. Ti ricordo che l'STL e' una delle poche librerie in giro per
le quali sono fornite delle garanzie sul comportamento asintotico delle
funzioni contenute.
In C uno deve sperare che la libreria che usa sia stata scritta tenendo
conto di esigenze il piu' possibile simili alle sue.
Mi convinco sempre piu' che non sai di cosa stai parlando.
Ciao,
Nicola

parti che causano problemi dal punto di vista prestazionale.
:-)
C'è del vero e c'è del falso.
La parte vera è che è importante la velocità relativa di ogni operazione. 
Relativa a cosa? All'operazione più lunga che avverrà in quel segmento di 
codice. Per fare un esempio... Si deve fare una SELECT sul database. La 
SELECT è una stringa che dovrà essere composta a runtime. Questa stringa 
sarà poi passata al DB. Di solito il rapporto fra il tempo necessario per 
costruire la stringa e il tempo per ricevere la risposta è tipo 1000:1. Cosa 
significa? Significa che è inutile perdere tempo a ottimizzare la fase di 
creazione della stringa. Perchè tanto vicino al tempo necessario per il DB 
per eseguire la SELECT è microscopico.
La parte falsa è che questa mentalità ha generato un lassismo tale che ogni 
nuova versione di un programma è più lenta della precedente (questo perchè 
l'ottimizzazione dovrebbe essere fatta a posteriori invece che a priori. A 
priori ci si deve accontantere che una cosa funzioni. Peccato che a 
posteriori non ci sia mai il tempo per ottimizzare. E se hai scritto del 
codice che per sua natura è lento resterà lento a meno di non riscriverlo) 
Operazioni che si possono fare in tempo costante diventano lineari, 
operazioni lineari diventano quadratiche. Per semplificare il programma 
tutto viene precaricato (esempi in programmi commerciali: l'Acrobat 6.0 
precaricava all'avvio tutti i plugin, con il risultato che ci volevano 
decine di secondi per lanciarlo. Con il 7.0 si sono resi conto che il 99% 
delle volte i plugin non li si usa, e quindi li carica on-demand. Stessa 
cosa per l'ACDSee). Poi la gente si lamenta "ma perchè la nuova versione del 
programma richiede il doppio della memoria e va veloce la metà?". Il secondo 
problema è che la differenza fra un buon programmatore e un programmatore 
meno buono è che il buon programmatore produrrà codice veloce. Il cattivo 
programmatore metterà in pratica (senza volerlo) tutte quelle pratiche 
"sbagliate" che rallentano il codice. Se iniziamo a dire che tanto la 
velocità non conta quindi diminuiamo la differenza fra un buon programmatore 
e un cattivo programmatore.
C'è anche un'altra motivazione pratica per non ottimizzare a posteriori: il 
tempo-programmatore costa più del tempo-CPU, quindi è più facile dire alla 
gente "compratevi un computer nuovo".
--- bye 

constructs such as if(myList.empty()) rather than if(MyList.size()==0).
Considerando che ci sono implementazioni (quella del VC++) in cui la classe 
string occupa più di 20 bytes uno si potrebbe aspettare che a fronte di 
un'occupazione potenzialmente enorme di una string per lo meno i servizi 
essenziali fossero ottimizzati al massimo.
Stessa cosa per le list in cui la size non è garantito che sia costante 
(questo in alcuni casi è dovuto al fatto che si è preferito avere una splice 
ottenibile sempre in tempi costanti. E' una decisione ingegneristica, ma non 
è la MIA decisione ingegneristica. Non è detto che ti serva sempre un 
martello, ma tutto ciò che ti dà le STL è un martello. Considerando che il 
90% dei programmatori STL probabilmente non usa la Splice ma vorrebbe usare 
la Size si può anche discutere se sia una buona decisione ingegneristica)
La domanda è "tu cammineresti su un pavimento che DOVREBBE reggere il tuo 
peso"? La risposta è "se posso no"
Ciao,
Nicola

 dove lo trovo il supporto alle eccezioni?
Forse qui?
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm/statem_31.asp
Oppure qui?
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmfc98/html/_mfc_Class_Library_Reference_Introduction.asp
Ciao,
Nicola Musatti

 peso"? La risposta è "se posso no"
Il problema e' che l'unica alternativa che tu presenti e' "il pavimento
me lo faccio io" e su un pavimento fatto da te cammnierei ancor meno.
Ciao,
Nicola Musatti

 gente "compratevi un computer nuovo".
Se e' una soluzione che al cliente costa meno, mi pare un approccio
sensato e corretto.
Ciao,
Nicola

 della macchina con cui si pu' avere a che fare piu' da 'vicino'.
Il punto e' che prima di conoscere il funzionamento dell'hardware ci
sono cose piu' importanti da imparare.
Ciao,
Nicola

us/vcmfc98/html/_mfc_Class_Library_Reference_Introduction.asp
Hai mescolato due cose diverse :-)
Il SEH è un exception handling per il C, con delle limitazioni. Esso è 
supportato dal Windows (è l'exception handling del Windows) ma in generale a 
meno di non dare un puntatore sbagliato a una funzione windows (e quindi di 
generare un GPF) la funzione Windows non ti tirerà mai un SEH.
Quoto dalla pagina "Exception Handling (MFC)"
Note   MFC supports both C++ exceptions and the MFC exception macros. MFC 
does not directly support Windows NT structured exception handlers (SEH), as 
discussed in Exception Handling (SEH).
Però è vero. L'MFC supporta le eccezioni e te ne tira parecchie. Troppi anni 
che ho abbandonato quella libreria (troppo pesante/troppi problemi).
Quindi il risultato è che per Windows c'è UNA libreria nota che tira le 
eccezioni. E se ben ricordo le MFC sono considerate una specie di abominio 
del C++ Interessante :-)
--- bye 

 del C++ Interessante :-)
come dire "mio nonno fuma, il treno fuma -> mio nonno è un treno"
:-)
-- 
MSN: sirpsycho_78 -at- hotmail dot com
the last action hero... 
http://tinyurl.com/bgy5w

 ClassObj & ClassObj :: operator + (const ClassObj & SecondArg)
Difficile che un operator+ possa restituire per reference.
Max

Max M. ha scritto:

Infatti, non dovrebbe essere quello di modifica ( += ) a restituire una 
reference ???
Ciao !

 Ciao !

aaaaaarrrrrrrrggggggggghhhhhhhhhhhhhhhh
Vergognati !!! :|
Sapessi quante volte succede a me :D
Soviet_Mario ha scritto:


 del C++ Interessante :-)
Bella o brutta che sia e' in assoluto la libreria C++ piu' usata per
programmare Windows. Considerato che anche le librerie Borland usano le
eccezioni, direi che e' difficile programmare in C++ su Windows senza
usarle.
Ciao,
Nicola


L'errore e' pensare che questo possa avvenire a costo zero. Se
migliorare le prestazioni di un'applicazione shrink-wrapped puo'
portare al raddoppio del suo prezzo torna ad essere preferibile
aggiornare il PC.
Il problema semmai e' che spesso i benefici di una nuova versione di un
applicativo non paiono valere i costi di aggiornamento, soprattutto se
il motivo fondamentale per il quale ci si aggiorna e' la presenza di
bachi non corretti nella versione corrente.
Ciao,
Nicola