- Çöp Toplamayı Unutun (Bunun yerine RAII kullanın). Çöp Toplayıcının bile sızıntı yapabileceğini (Java / C # 'da bazı referansları "geçersiz kılmayı unutursanız) ve Çöp Toplayıcının kaynakları elden çıkarmanıza yardımcı olmayacağını unutmayın (bir tutamaç edinmiş bir nesneniz varsa bir dosya varsa, nesne kapsam dışına çıktığında, bunu Java'da elle yapmazsanız veya C # 'da "dispose" kalıbını kullanırsanız dosya otomatik olarak serbest bırakılmaz).
- "İşlev başına bir dönüş" kuralını unutun . Bu, sızıntıları önlemek için iyi bir C tavsiyesidir, ancak istisnaları kullanması nedeniyle C ++ 'da güncelliğini yitirmiştir (bunun yerine RAII kullanın).
- Ve "Sandviç Modeli" iyi bir C tavsiyesi olsa da , istisnaların kullanımı nedeniyle C ++ 'da güncelliğini yitirmiştir (bunun yerine RAII kullanın).
Bu gönderi tekrarlı gibi görünüyor, ancak C ++ 'da bilinmesi gereken en temel kalıp RAII'dir .
Hem boost, TR1 hem de düşük (ancak genellikle yeterince verimli) auto_ptr'den (ancak sınırlamalarını bilmelisiniz) akıllı işaretçileri kullanmayı öğrenin.
RAII, C ++ 'da hem istisnai güvenlik hem de kaynak kullanımının temelidir ve başka hiçbir model (sandviç vb.) Size ikisini birden vermez (ve çoğu zaman size hiçbir şey vermez).
Aşağıda RAII ve RAII olmayan kodun karşılaştırmasına bakın:
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.
}
Özetlemek gerekirse ( Ogre Mezmur 33'ün yorumundan sonra ), RAII üç kavrama dayanır:
- Nesne bir kez inşa edildiğinde, sadece çalışır! Yapıcıdaki kaynakları edinin.
- Nesne imhası yeterli! Yıkıcıda ücretsiz kaynaklar yapın.
- Her şey kapsamlarla ilgili! Kapsamlı nesneler (yukarıdaki doRAIIStatic örneğine bakın) bildirimlerinde oluşturulacak ve çıkış nasıl olursa olsun (dönüş, kesme, istisna, vb.) Yürütme kapsamdan çıktığı anda yok edilecektir.
Bu, doğru C ++ kodunda çoğu nesnenin oluşturulmayacağı newve bunun yerine yığın üzerinde bildirileceği anlamına gelir . Ve kullanılarak inşa edilenler için new, tümü bir şekilde kapsamlı olacaktır (örneğin, akıllı bir işaretçiye iliştirilmiş).
Bir geliştirici olarak, bu gerçekten çok güçlüdür, çünkü manuel kaynak işlemeyi önemsemeniz gerekmeyecektir (C'de yapıldığı gibi veya Java'daki bazı nesneler için try/ finallybu durumda yoğun şekilde kullanılır ) ...
Düzenle (2012-02-12)
"kapsamlı nesneler ... çıkış ne olursa olsun ... yok edilecek" bu tamamen doğru değil. RAII'yi aldatmanın yolları vardır. herhangi bir terminate () çeşidi temizlemeyi atlayacaktır. exit (EXIT_SUCCESS) bu bağlamda bir tezattır.
- wilhelmtell
wilhelmtell bu konuda oldukça haklı: RAII'yi aldatmak için istisnai yollar vardır , bunların hepsi sürecin aniden durmasına neden olur.
Bunlar istisnai yollardır çünkü C ++ kodu sonlandırma, çıkış vb. İle karıştırılmamıştır veya istisnalar olması durumunda, işlenmemiş bir istisna istiyoruz. , işlemin çökmesi ve çekirdeğin bellek görüntüsünü temizledikten sonra değil olduğu gibi çökertmesi için .
Ancak yine de bu vakaları bilmeliyiz çünkü nadiren olsa da yine de olabilirler.
( C ++ kodunu kim arıyor terminateya exitda sıradan mı? ... GLUT ile oynarken bu problemle uğraşmak zorunda olduğumu hatırlıyorum : Bu kütüphane, C ++ geliştiricileri için işleri önemsememek gibi zorlaştıracak şekilde aktif olarak tasarlamaya kadar çok C odaklıdır. Yığın ayrılmış veriler hakkında veya ana döngülerinden asla geri dönmemek konusunda "ilginç" kararlar almak hakkında ... Bu konuda yorum yapmayacağım) .