Da C a C++

[Luc@s]

Cosa cambia da programmare in C++ rispetto a C oltre alle classi, l'ereditarietà ???????????


P.S: ma scanf() e printf() e tutta li libreria standard del C, si puo usare in C++????????
P.P.S: si puo programmare il C++, come se fosse C?????

[Luc@s]

come libro va bene questo ?????????

[cionci]

Ottimo libro...

[Luc@s]

Originariamente inviato da cionci
[b]Ottimo libro...

Allora mo, se domani me va bene l'orale me lo prendo entro 1 mese



P.S: mi risponderesti al post sull'overloading????????
P.P.S: cosa sono istream e ostream??????? io ho pensato che potrebbere essere i 2 flussi di impot uotput.............. ho sbagliato?

[cionci]

Originariamente inviato da Luc@s
[b]

Allora mo, se domani me va bene l'orale me lo prendo entro 1 mese



P.S: mi risponderesti al post sull'overloading????????
P.P.S: cosa sono istream e ostream??????? io ho pensato che potrebbere essere i 2 flussi di impot uotput.............. ho sbagliato?

Sì...in pratica sono quello che dici tu...sono sequenze di input ed output---
Ti ho appena risposto all'altra domanda...

[Luc@s]

ma cosa cambia tra scrivere i files di intestazione con il .h????????
E poi sta STL è obbligatorio usarla?

[cionci]

Originariamente inviato da Luc@s
[b]ma cosa cambia tra scrivere i files di intestazione con il .h????????
E poi sta STL è obbligatorio usarla?

E' una questione di standard... Gli ultimi standard per il C++ prevedono che non si usi il .h... Dal punto di vista del file di intestazione non cambia niente...

La STL certo non è obbligatorio usarla, ma fai meglio ad usarla proprio per una questione di convenienza...pensa solo a string in confronto ai vecchi vettori di caratteri del C

[/\/\@®¢Ø]

Originariamente inviato da Luc@s
[b]Cosa cambia da programmare in C++ rispetto a C oltre alle classi, l'ereditarietà ???????????

In piu' rispetto al C il C++ ha oltre alle classi e all'ereditarieta:
- templates, ovvero classi, strutture e funzioni parametrizzate.
Ad esempio set<int> e' un insieme di interi, mentre set<char*> e' un insieme di puntatori a caratteri.
- gestione delle eccezioni ( come in Java tanto per chiarirsi ).

Ci sono poi altre differenze piu' o meno nascoste ( e subdole ) pero' quelle piu' consistenti sono queste ( mi sembra ).

[b]

P.S: ma scanf() e printf() e tutta li libreria standard del C, si puo usare in C++????????
P.P.S: si puo programmare il C++, come se fosse C?????

Si puo' benissimo, solo che e' consigliabile usare gli header opportuni: al posto di stdlib.h dovresti includere cstdlib, al posto di stdio.h usare cstdio e cosi' via.

[/\/\@®¢Ø]

Originariamente inviato da Luc@s
[b]ma cosa cambia tra scrivere i files di intestazione con il .h????????
E poi sta STL è obbligatorio usarla?

i files di intestazione col .h sono mantenuti per compatibilita' col passato, e un compilatore potrebbe neanche averli, e' quindi consigliabile passare direttamente alle intestazioni giuste ( senza .h )
La STL la usi se ti serve .
Personalmente la preferisco alla libreria standard del C, anche perche' e' decisamente piu' completa e semplice, una volta che ci fai la mano.

[Luc@s]

esiste una guida per imparare l'SLT in inglese ma skarikabile????????
Come libro, mi consigliereste questo ????

[Luc@s]

mi spieghi la gestione delle eccezioni( da quel che ho capito si fa con try........ giusto?..........

[/\/\@®¢Ø]

E' un discorso che e' difficile spiegare in poche righe, faro' il possibile...

Forse la cosa piu' semplice e' partire con un esempio ( idiota ):

try{
  string x = "filename.txt";
  FILE y = f(x);
  [b]if ( y == 0 ) throw IOError;[/b]
  /* altriment continuiamo l'elaborazione */
...
} catch( IOError e )
{ /* c'e' stato un errore */
  cout << "file invalido" << endl;
}

le la funzione f ritorna un valore 0 il file non puo' essere letto e lanciamo l'eccezione: quando scriviamo throw IOError ( dove IOError e' una qualsiasi struttura che abbiamo preventivamente definito ) il programma interrompe l'esecuzione del codice e continua dall'istruzione catch. Questo e' simile alla classica gestione in "stile C" ( controllo del valore di ritorno ) nei casi semplici. Se pero' io nel codice che ho scritto chiamo una funzione che getta delle eccezioni, posso evitare di fare i controlli nel codice e limitare a fare i catch. Nell'esempio di prima , supponiamo che la funzione f invece di ritornare 0 faccia un throw IOError lei stessa in caso di errore. Allora il nostro codice diventa :

try{
  string x = "filename.txt";
  FILE y = f(x);
...
} catch( IOError e )
{ /* c'e' stato un errore */
  cout << "file invalido" << endl;
}

Che e' un po' piu' chiaro. Oltretutto se io chiamo due,tre, dieci volte la funzione f, mi basta avere un unico catch per 'intercettare' gli errori. E inoltre se a sua volta f chiama altre funzioni che possono avere errori simili io le 'intercetto' tutte allo stesso livello.
Questo e' molto comodo nell'IO perche' mi permette di evitare di controllare lo stato del canale di input ogni volta che faccio una lettura. Ad esempio supponi di fare un server web che accetta connessioni via internet. Se il canale di input supporta le eccezioni, Invece che controllare continuamente che la connessione non sia caduta, puoi scrivere il codice senza pensare agli errori di lettura, 'inglobare' il codice tra try e catch, e nel catch semplicemente chiudere la connessione ed aspettare la prossima:

while ( runServer )
{
 try
 {
    // aspettiamo la richiesta di input
    iostream client( socket );
    Request rq;
    Response rs;
    readRequest( client , rq );
    prepareResponse( rq , rs );
    writeResponse( client , rs ); 
  }catch( IOError e )
  {
   /* connessione caduta, avanti il prossimo ! */
  }
}

In qualsiasi punto venga lanciata l'eccezione ( durante la lettura della richiesta, durante la scrittura della risposta ) in caso di errore il controllo viene dato alla routine di gestione dell'errore: l'idea e' che solo a piu' alto livello so come comportarmi , nelle routines di lettura posso solo individuare l'errore e segnalarlo. IOError e' comunque una struttura ( o una classe ) e tutti gli effetti e quindi se e' dotata di metodi o di campi li posso usare nel 'catch' per avere migliori informazioni sull'errore.


Ci sono ancora moltissimi altri aspetti... pero' probabilmente ho gia' scritto anche troppo !

Il libro di Lippman e' un buon libro, ho sentito solo che pareri positivi .
Per il manuale meglio se cerchi con Google, dovresti trovarne parecchi su internet .