- Dimentica Garbage Collection (usa invece RAII). Si noti che anche Garbage Collector può perdere anche (se si dimentica di "null" alcuni riferimenti in Java / C #) e che Garbage Collector non ti aiuterà a smaltire le risorse (se si dispone di un oggetto che ha acquisito un handle per un file, il file non verrà liberato automaticamente quando l'oggetto uscirà dall'ambito se non lo si fa manualmente in Java, o si utilizza il modello "dispose" in C #).
- Dimentica la regola "un ritorno per funzione" . Questo è un buon consiglio C per evitare perdite, ma è obsoleto in C ++ a causa del suo uso di eccezioni (usare RAII invece).
- E mentre il "modello a sandwich" è un buon consiglio in C, è obsoleto in C ++ a causa del suo uso di eccezioni (usa RAII invece).
Questo post sembra essere ripetitivo, ma in C ++, il modello più semplice da sapere è RAII .
Impara a usare i puntatori intelligenti, sia da boost, TR1 o anche da auto_ptr (ma spesso abbastanza efficiente) (ma devi conoscerne i limiti).
RAII è la base della sicurezza delle eccezioni e dello smaltimento delle risorse in C ++, e nessun altro modello (sandwich, ecc.) Ti darà entrambi (e il più delle volte, non ti darà nessuno).
Vedi sotto un confronto di codice RAII e non RAII:
void doSandwich()
{
T * p = new T() ;
// do something with p
delete p ; // leak if the p processing throws or return
}
void doRAIIDynamic()
{
std::auto_ptr<T> p(new T()) ; // you can use other smart pointers, too
// do something with p
// WON'T EVER LEAK, even in case of exceptions, returns, breaks, etc.
}
void doRAIIStatic()
{
T p ;
// do something with p
// WON'T EVER LEAK, even in case of exceptions, returns, breaks, etc.
}
A proposito di RAII
Per riassumere (dopo il commento di Ogre Psalm33 ), RAII si basa su tre concetti:
- Una volta che l'oggetto è stato costruito, funziona e basta! Acquisisci risorse nel costruttore.
- La distruzione dell'oggetto è sufficiente! Fai risorse gratuite nel distruttore.
- Si tratta di ambiti! Gli oggetti con ambito (vedi l'esempio doRAIIStatic sopra) saranno costruiti alla loro dichiarazione e saranno distrutti nel momento in cui l'esecuzione esce dall'ambito, indipendentemente da come l'uscita (ritorno, interruzione, eccezione, ecc.).
Ciò significa che nel corretto codice C ++, la maggior parte degli oggetti non verrà costruita con newe verrà invece dichiarata nello stack. E per quelli costruiti usando new, tutto sarà in qualche modo mirato (ad esempio collegato a un puntatore intelligente).
Come sviluppatore, questo è davvero molto potente in quanto non dovrai preoccuparti della gestione manuale delle risorse (come fatto in C, o per alcuni oggetti in Java che fanno un uso intensivo di try/ finallyper quel caso) ...
Modifica (2012-02-12)
"Gli oggetti con ambito ... verranno distrutti ... indipendentemente dall'uscita" non è del tutto vero. ci sono modi per imbrogliare RAII. qualsiasi sapore di terminate () ignorerà la pulizia. exit (EXIT_SUCCESS) è un ossimoro in questo senso.
- Wilhelmtell
Wilhelmtell ha ragione: ci sono modi eccezionali per imbrogliare RAII, il che porta a un brusco arresto del processo.
Questi sono modi eccezionali perché il codice C ++ non è disseminato di terminare, uscire, ecc., O nel caso delle eccezioni, vogliamo un'eccezione non gestita per arrestare il processo e scaricare la memoria come core, e non dopo la pulizia.
Ma dobbiamo ancora conoscere questi casi perché, anche se raramente accadono, possono ancora accadere.
(chi chiama terminateo exitnel codice C ++ casuale? ... Ricordo di aver dovuto affrontare quel problema quando giocavo con GLUT : questa libreria è molto orientata al C, arrivando al punto di progettarla attivamente per rendere le cose difficili per gli sviluppatori C ++ come non preoccuparsene sullo stack di dati allocati o sull'avere decisioni "interessanti" sul non tornare mai dal loro ciclo principale ... non commenterò al riguardo) .