[C++]Guida C++

[InformaticoRC]

Salve forum,

Volevo chiedervi se conoscete una guida COMPLETA MA CONCISA di C++ da trovare online che mi permetta in poco tempo di conoscere bene questo linguaggio, permettendomi di programmare senza difficoltà.
GRAZIE ;)

[clockover]

Comincia da qui http://www.cplusplus.com/doc/tutorial/

[InformaticoRC]

Comincia da qui http://www.cplusplus.com/doc/tutorial/

ehm...niente in italiano? :D

[ndakota]

"guida completa e concisa", "C++", "in poco tempo" e "senza difficoltà" non dovrebbe essere messe in una stessa frase :O

[british]

Salve forum,

Volevo chiedervi se conoscete una guida COMPLETA MA CONCISA di C++ da trovare online che mi permetta in poco tempo di conoscere bene questo linguaggio, permettendomi di programmare senza difficoltà.
GRAZIE ;)

non si può. comprati un (buon) libro (o più di uno) e preparati a sudare.

ciao!

[Freaxxx]

io ho un libro che introduce al C++ e fa accenni di UML e sono 800 pagine solo per parlare un po' di sintassi e strutture, pagina più pagina meno, ci sono libri solo sui puntatori da 300-400 pagine, tieni presente che vuoi approcciare uno dei linguaggi più ostici in circolazione.

se vuoi massimizzare l'uso del tempo a tua disposizione leggiti qualcosa su un linguaggio ad alto livello come Java, Python o Ruby che sono più approcciabili del C++, se vuoi imparare il C++, dedicagli tanto tempo.

[Tommo]

"guida completa e concisa", "C++", "in poco tempo" e "senza difficoltà" non dovrebbe essere messe in una stessa frase :O

Per non dire "in italiano" :D

[clockover]

Poveretto gli avete completamente smontato tutti i sogni

[pabloski]

Purtroppo è così, non si è mai sentito di una guida al C++ che fosse semplice, corta, tipo tutorial ed inoltre in italiano.

Mi sa che devi procurarti il libro di Stroustrup o quello di Eckel. Il primo è meno pesante e più schematico.

[cdimauro]

Con lo Stroustrup come minimo lo vediamo volare dalla finestra in preda alla disperazione.

Ha tutto, viene considerata la bibbia, ma è anche un mattone. Roba da programmatori navigati, insomma.

Eckel è già molto più potabile.

[banryu79]

Con lo Stroustrup come minimo lo vediamo volare dalla finestra in preda alla disperazione.

Ha tutto, viene considerata la bibbia, ma è anche un mattone. Roba da programmatori navigati, insomma.

Eckel è già molto più potabile.
Quoto e, beh, anche il C++ è roba da programmatori navigati, a ben guardare :)
Se però a InformaticoRC serve *esattamente* quello, non si scappa.

[InformaticoRC]

Come libro ho già quello di Deitel&Deitel "C++, Fondamenti di programmazione", però cercavo qualcosa di più immediato appunto, come guide e tutorial in modo da acquisire più velocemente una buona conoscenza.

[Freaxxx]

Come libro ho già quello di Deitel&Deitel "C++, Fondamenti di programmazione", però cercavo qualcosa di più immediato appunto, come guide e tutorial in modo da acquisire più velocemente una buona conoscenza.

ad iniziare adesso non finiresti tra 10 anni con il C++, non esiste un approccio veloce al C++, questo devi capire, inoltre il C++ ha features più uniche che rare nel mondo odierno dei linguaggi come i puntatori e l'eredità multipla, questi 2 argomenti presi da soli ti possono tenere impegnato per anni a studiarli.

[Tommo]

ad iniziare adesso non finiresti tra 10 anni con il C++, non esiste un approccio veloce al C++, questo devi capire, inoltre il C++ ha features più uniche che rare nel mondo odierno dei linguaggi come i puntatori e l'eredità multipla, questi 2 argomenti presi da soli ti possono tenere impegnato per anni a studiarli.

E oddio l'ereditarietà multipla "anni" mi sembra proprio eccessivo :D
E alla fine qualsiasi persona sana di mente usa implicitamente un modello a ereditarietà singola + interfacce, con il vantaggio che le interfacce possono anche contenere qualche metodo con un comportamento di default.
Purtroppo l'ereditarietà multipla di C++ è rotta (come tante altre cose), e lo standard lascia spazio ad un mucchio di comportamenti undefined in parecchi casi tipo diamond inheritance, ambiguous casting, uso coi template, e tante altre simpatiche perdite di tempo infinite :D

I puntatori sono un'altra bestia - il prossimo che li chiama "i puntatori" gli stacco le mani :asd:
E' più corretto dire che C/C++ offrono un "accesso di basso livello alla memoria" e quindi ti permettono di gestire l'aritmetica degli indirizzi, la posizione in memoria degli oggetti, se mettere qualcosa sullo stack o sull'heap, etc.
"I puntatori" sono semplicemente uno dei mezzi con il quale si manipola la memoria in C++... e sono assolutamente banali nel momento in cui sai che cosa stai facendo.

Ovviamente questo non vuol dire che il C++ sia banale, perchè gestire a mano la memoria è tipo la causa del 99% dei bug per i principianti :D

PS: con i puntatori, ASSERT() è tuo amico.

[Freaxxx]

E oddio l'ereditarietà multipla "anni" mi sembra proprio eccessivo :D
E alla fine qualsiasi persona sana di mente usa implicitamente un modello a ereditarietà singola + interfacce, con il vantaggio che le interfacce possono anche contenere qualche metodo con un comportamento di default.
Purtroppo l'ereditarietà multipla di C++ è rotta (come tante altre cose), e lo standard lascia spazio ad un mucchio di comportamenti undefined in parecchi casi tipo diamond inheritance, ambiguous casting, uso coi template, e tante altre simpatiche perdite di tempo infinite :D

I puntatori sono un'altra bestia - il prossimo che li chiama "i puntatori" gli stacco le mani :asd:
E' più corretto dire che C/C++ offrono un "accesso di basso livello alla memoria" e quindi ti permettono di gestire l'aritmetica degli indirizzi, la posizione in memoria degli oggetti, se mettere qualcosa sullo stack o sull'heap, etc.
"I puntatori" sono semplicemente uno dei mezzi con il quale si manipola la memoria in C++... e sono assolutamente banali nel momento in cui sai che cosa stai facendo.

Ovviamente questo non vuol dire che il C++ sia banale, perchè gestire a mano la memoria è tipo la causa del 99% dei bug per i principianti :D

PS: con i puntatori, ASSERT() è tuo amico.

Mi complimento con te ma non credo che la media sia questa, basti pensare ad uno dei perché della nascita di un certo Java, nato anche per ovviare a problemi ed errori di programmazione sulla gestione della memoria.

Si potrebbe poi parlare dei vari compilatori che ci mettono comunque il loro zampino dato che trattano il linguaggio, e lo standard del linguaggio non specifica proprio tutto al 100%, e quello che non è specificato ogni compilatore lo implementa come meglio crede.

Se fosse realmente così facile la gestione della memoria non ci sarebbero tanti errori in programmazione e tanti libri sull'argomento.

[WarDuck]

Mi complimento con te ma non credo che la media sia questa, basti pensare ad uno dei perché della nascita di un certo Java, nato anche per ovviare a problemi ed errori di programmazione sulla gestione della memoria.

Si potrebbe poi parlare dei vari compilatori che ci mettono comunque il loro zampino dato che trattano il linguaggio, e lo standard del linguaggio non specifica proprio tutto al 100%, e quello che non è specificato ogni compilatore lo implementa come meglio crede.

Se fosse realmente così facile la gestione della memoria non ci sarebbero tanti errori in programmazione e tanti libri sull'argomento.

Diciamo che la gestione della memoria tipicamente a tutto serve tranne che a risolvere il problema che stai cercando di risolvere.

Gestire la memoria è qualcosa di vicino alla macchina, mentre tu vorresti degli strumenti che fossero più vicini al tuo modo di ragionare.

Per questo motivo sono stati introdotti linguaggi e implementazioni di linguaggi che consentissero di liberarsi dalla gestione della memoria.

In alcuni contesti ovviamente non se ne può fare a meno, ma nella maggior parte dei casi gestire la memoria (ed eventuali bug che possono derivarne) è solo una tremenda perdita di tempo per il programmatore.

[Tommo]

Se fosse realmente così facile la gestione della memoria non ci sarebbero tanti errori in programmazione e tanti libri sull'argomento.

Guarda che il mio rant era a proposito dell'uso della frase "imparare i puntatori" al posto di "imparare la struttura della memoria"...
non ho affatto detto che è facile, anzi, imparare "i puntatori" a memoria è pure più facile che capire veramente la macchina e che cosa stai facendo.

E' anche vero che se provi a andare pointer-heavy in C++ e non sai nemmeno cos'è l'heap, la cosa finirà malissimo :asd:

[Freaxxx]

Diciamo che la gestione della memoria tipicamente a tutto serve tranne che a risolvere il problema che stai cercando di risolvere.

Gestire la memoria è qualcosa di vicino alla macchina, mentre tu vorresti degli strumenti che fossero più vicini al tuo modo di ragionare.

Per questo motivo sono stati introdotti linguaggi e implementazioni di linguaggi che consentissero di liberarsi dalla gestione della memoria.

In alcuni contesti ovviamente non se ne può fare a meno, ma nella maggior parte dei casi gestire la memoria (ed eventuali bug che possono derivarne) è solo una tremenda perdita di tempo per il programmatore.

si, però non consideri le caratteristiche intrinseche al linguaggio così, o meglio, se una persona non vuole curare un suo "garbage collector" et similia, magari usa un altro linguaggio, magari qualcosa come C# e Java.

Guarda che il mio rant era a proposito dell'uso della frase "imparare i puntatori" al posto di "imparare la struttura della memoria"...
non ho affatto detto che è facile, anzi, imparare "i puntatori" a memoria è pure più facile che capire veramente la macchina e che cosa stai facendo.

E' anche vero che se provi a andare pointer-heavy in C++ e non sai nemmeno cos'è l'heap, la cosa finirà malissimo :asd:

in tutti i testi che ho preso in mano fino ad ora, in tutti gli articoli online letti, i puntatori si chiamano puntatori, con questo non dico che certamente la nomenclatura è corretta, ma lo standard de facto è questo.

ovvio che stack, heap e meccanismi basta su valori referenziati sono alla base della base di ogni discorso del genere :)

[WarDuck]

Quello che intendeva dire Tommo è che i puntatori sono uno strumento per accedere alla memoria.

Il loro utilizzo è di fatto "semplice" se si conosce perfettamente la struttura della memoria.

Buona parte degli errori è dovuto spesso al fatto di non conoscere la struttura della memoria.

Ad esempio stiamo lavorando su un simulatore in C, avevamo una funzione che prende in ingresso un puntatore e lo modifica a seconda dei casi.

La funzione era stata scritta così:


void func( int* ptr )
{
switch( something )
{
case A:
ptr = x;
break;
case B:
ptr = y;
break;
}
}


Ovviamente questa funzione è sbagliata, perché non cambia il valore del puntatore esterno, ma lo cambia solo localmente alla funzione.

Quindi alla fine avevi che ptr era sempre un puntatore sballato.

Questo è un caso eclatante, ma spesso è difficile beccare errori nella gestione della memoria.

Comunque lavorando per un po' di mesi su questo progetto ho potuto verificare che la maggior parte degli errori si verifica o per via di strutture non inizializzate (avevamo una struttura allocata con malloc che a volte risultava inizializzata altre volte no), o per via di mancati controlli sui puntatori.

Insomma cose che dovrebbero rientrare nelle "best practices".