> // aici v este șters automat
Atunci când vectorul v este distrus, acesta este responsabil pentru distrugerea tuturor obiectelor Widget pe care le conține. Să presupunem că v conține 10 obiecte Widget, iar în timpul distrugerii primei dintre ele o excepție este aruncată. Restul celor nouă obiecte Widget trebuie, de asemenea, să fie distruse (altfel resursele alocate acestora vor fi pierdute), deci trebuie să le numiți și destructori. Dar imaginați-vă că în acest moment destructorul obiectului Widget al doilea va ridica și o excepție. Apoi vor exista doar două excepții active simultan, care este prea mult pentru C ++. În funcție de condițiile specifice, executarea programului va fi fie întreruptă, fie comportamentul său va fi incert. În acest exemplu, apare cel de-al doilea caz. Și acest lucru se va întâmpla când se utilizează orice container de bibliotecă (de exemplu, listă, set), orice container TR1 (vezi regula 54) și chiar un tablou. Și cauza acestei probleme nu este în containere sau în tablouri. Terminarea prematură a programului sau comportamentul nedefinit este rezultatul faptului că distrugătorii fac excepții. C ++ nu-i plac distrugătorii care generează excepții!
Acest lucru este destul de ușor să înțelegeți. Dar ce ar trebui să faceți dacă trebuie să efectuați o operațiune în distrugătorul dvs., care poate face o excepție? De exemplu, să presupunem că avem de-a face cu o clasă care descrie o conexiune la o bază de date:
static DBConnection crea (); // funcția returnează un obiect
// DBConnection; parametrii pentru
void close (); // închideți conexiunea; pe eșec
Pentru a ne asigura că clientul nu uită să închidă obiectele DBConnection, este rezonabil să creezi o clasă pentru gestionarea resurselor DBConnection, care apelează aproape la distrugător. Clasele care gestionează resursele, vom examina mai detaliat capitolul 3 și aici este suficient să ne dăm seama ce ar trebui să arate distrugătorul acestei clase:
clasa DBConn
DBConn () // asigură conectarea la baza de date
Trimiteți-le prietenilor: