Regula zero în C - C fluent
Acum, când suntem clare cu privire la funcțiile generate de compilator, Regula celor trei și Regula celor cinci, să le folosim pentru a reflecta la modul de utilizare a funcției „= implicite” pentru a avea un cod expresiv și corect.
Într-adevăr, C ++ 11 a adăugat posibilitatea de a cere de la compilator să scrie o implementare implicită pentru aceste metode ale unei clase:
Dar compilatorul poate genera aceste funcții, chiar dacă nu le specificăm în interfață. Am văzut că această caracteristică C ++ avea unele complexități, dar în cazul de mai sus oricum, codul este perfect echivalent cu acesta:
Aceasta ridică o întrebare: dacă compilatorul este capabil să ofere o implementare implicită, ar trebui să scriem = implicit pentru a fi mai explicit chiar și atunci când acest lucru nu schimbă codul generat? Sau este o verbozitate gratuită? Ce cale este mai expresivă?
Am avut dezbaterea cu colegii mei (pălărie pentru ei), am săpat în jur pentru a-mi da seama că a fost o dezbatere fierbinte: Ghidurile de bază C ++ au o opinie, Scott Meyers are o opinie și nu sunt de acord cu fiecare alte. Să vedem despre ce este vorba.
C ++ Core Guidelines & R. Martinho Fernandes: The Rule of Zero
Liniile directoare de bază C ++ sunt foarte clare în legătură cu această întrebare, ghidul de deschidere privind constructorii precizând:
C.20: Dacă puteți evita definirea operațiilor implicite, faceți.
Dreapta. Destul de clar. Acum, care este rațiunea din spatele acestui ghid?
Motiv Este cel mai simplu și oferă cea mai curată semantică. [Dacă toți membrii] au toate funcțiile speciale, nu este nevoie de alte lucrări.
Și ghidul continuă spunând că acest lucru este cunoscut sub numele de „Regula zero„.
Acest termen a fost inventat de R. Martinho Fernandes, într-o postare de blog din 2012 (mulțumesc utilizatorului Lopo și utilizatorului Redditphere991 pentru că a dezgropat postarea).
Care este exact Regula zero? Merge astfel: Clasele care declară destructori personalizați, constructori de copiere/mutare sau operatori de atribuire de copiere/mutare ar trebui să se ocupe exclusiv de proprietate. Alte clase nu trebuie să declare destructori personalizați, constructori de copiere/mutare sau operatori de atribuire de copiere/mutare (Rule of Zero ușor reformulat de Scott Meyers).
Conform Rule of Zero, există două opțiuni în ceea ce privește funcțiile pe care compilatorul le poate genera: fie că toate au o implementare non-trivială care se ocupă de proprietate, fie că niciuna dintre ele nu este declarată.
Cu excepția faptului că, dacă îl priviți cu atenție, Rule of Zero nu spune nimic despre constructorul implicit X (). Menționează doar cele 5 funcții care altfel participă la Regula celor Cinci. Ca o reamintire, Regula celor cinci spune că dacă una dintre cele 5 funcții de gestionare a resurselor (constructori de copiere/mutare, operatori de alocare copiere/mutare, destructor) a avut o implementare non-banală, celelalte ar trebui să aibă cu siguranță o implementare non-banală de asemenea.
Deci, ce zici de constructorul implicit? Dacă implementarea sa este banală, ar trebui să o declarăm cu = implicit sau să nu o declarăm deloc și să lăsăm compilatorul să facă treaba?
Dar C ++ Core Guideline C.20 pare să ne încurajeze să nu o declarăm nici:
C.20: Dacă puteți evita definirea operațiilor implicite, faceți.
Încă destul de clar.
Scott Meyers: Regula celor cinci valori implicite
Scott Meyers scrie ca răspuns la Rule of Zero că prezintă un risc.
Într-adevăr, declararea oricăreia dintre cele 5 funcții are un efect secundar asupra generării automate a operațiunilor de mutare. Un efect secundar destul de dur, deoarece dezactivează generarea automată a operațiunilor de mutare. (Dacă vă întrebați de ce operațiile de mutare în mod specific, aruncați o privire la actualizarea funcțiilor generate de compilator, regula celor trei și regula celor cinci).
În special, dacă adăugați un destructor la clasă:
Apoi își pierde operațiunile de mutare. DAR nu își pierde operațiunile de copiere! Deci, codul clientului va continua să se compileze, dar va apela în tăcere copiere în loc de mutare. Acest lucru nu este bun.