C ++ 'da oyun geliştirme kapsamında, işaretçilerin kullanımında tercih ettiğiniz kalıplar hangileridir (hiç biri, ham, kapsamlı, paylaşılmış veya başka türlü akıllı ve dilsiz)?
Düşünebilirsin
Yanıtlar:
Çeşitli yaklaşımları denedikten sonra bugün kendimi Google C ++ Stil Kılavuzuyla uyumlu buluyorum :
İşaretçi anlambilimine gerçekten ihtiyacınız varsa, scoped_ptr harikadır. Std :: tr1 :: shared_ptr dosyasını, nesnelerin STL kapları tarafından tutulması gerektiğinde olduğu gibi çok özel koşullar altında kullanmalısınız. Asla auto_ptr kullanmamalısınız. [...]
Genel olarak konuşursak, kodun net nesne sahipliği ile kod tasarlamayı tercih ediyoruz. En net nesne sahipliği, bir işaretçi kullanmadan doğrudan bir alan veya yerel değişken olarak bir nesneyi kullanarak elde edilir. [..]
Önerilmemelerine rağmen, referans sayılan işaretçiler bazen bir sorunu çözmenin en basit ve en şık yoludur.
Ayrıca "güçlü mülkiyet" düşünce trenini takip ediyorum. Uygun olduğunda, "bu sınıfın bu üyeye sahip olduğunu" açıkça ifade etmeyi seviyorum.
Nadiren kullanırım shared_ptr. Yaparsam, weak_ptrne zaman yapabilirsem serbestçe kullanırım , böylece referans sayısını artırmak yerine nesneye tutacağı gibi davranabilirim.
Her scoped_ptryerde kullanıyorum. Bariz sahiplik gösterir. Bir üyeye sadece böyle nesneler yapmamamın tek sebebi, eğer bir skop_ptr'de olduklarını bildirmek için onları ileriye götürebilirsin.
Bir nesne listesine ihtiyacım olursa kullanırım ptr_vector. Daha verimli ve kullanmaktan daha az yan etkisi var vector<shared_ptr>. Sanırım ptr_vector içindeki yazıyı bildirmeyi başaramayacağınızı düşünüyorum (bir süre oldu), ancak bunun anlambilimi bence buna değer. Temel olarak listeden bir nesneyi kaldırırsanız, otomatik olarak silinir. Bu aynı zamanda bariz mülkiyeti de göstermektedir.
Bir şeye atıfta bulunmam gerekiyorsa, onu çıplak bir işaretçi yerine referans yapmaya çalışıyorum. Bazen bu pratik değildir (yani, nesne oluşturulduktan sonra bir referansa ihtiyacınız olduğunda). Her iki durumda da, referanslar açıkça nesnenin size ait olmadığını ve başka yerlerde paylaşılan işaretçi anlambilimini takip ediyorsanız çıplak işaretçiler genellikle herhangi bir karışıklığa neden olmaz (özellikle "el ile silmeyi kaldırma" kuralını izlerseniz) .
Bu yöntemle, üzerinde çalıştığım bir iPhone oyunu yalnızca tek bir deleteçağrı yapabiliyordu ve bu yazı Obj-C'den C ++ köprüsüne yazıyordu.
Genel olarak hafıza yönetiminin insanlara bırakılamayacak kadar önemli olduğu kanısındayım. Silme işlemini otomatik hale getirebilirseniz, yapmalısınız. Paylaşılan_ptr ek yükü çalışma zamanında çok pahalıysa (diş açma desteğini kapattığınızı varsayarsak), dinamik ayırma işlemlerinizi düşürmek için muhtemelen başka bir şey kullanıyor olmalısınız.
İş için doğru aracı kullanın.
Programınız istisnalar atabiliyorsa, kodunuzun istisna olduğunun farkında olun. Akıllı işaretçiler kullanarak, RAII ve 2 fazlı yapımdan kaçınmak iyi bir başlangıç noktasıdır.
Açık bir mülkiyet semantiği olmayan döngüsel referanslarınız varsa, bir çöp toplama kütüphanesi kullanmayı veya tasarımınızı yeniden düzenlemeyi düşünebilirsiniz.
İyi kütüphaneler, konsepte tip değil kodlama yapmanıza izin verir, bu nedenle çoğu durumda kaynak yönetimi sorunlarının ötesinde ne tür bir işaretçi kullandığınız önemli değildir.
Çok iş parçacıklı bir ortamda çalışıyorsanız, nesnenizin potansiyel olarak iş parçacıkları arasında paylaşılıp paylaşılmadığını anladığınızdan emin olun. Boost :: shared_ptr veya std :: tr1 :: shared_ptr komutunu kullanmayı düşünmenizin ana nedenlerinden biri, iş parçacığı güvenli bir başvuru sayımı kullanmasıdır.
Referans sayımlarının ayrı tahsis edilmesinden endişe ediyorsanız, bunun çevresinde birçok yol vardır. Boost :: shared_ptr kütüphanesini kullanarak referans sayaçlarını tahsis edebilir ya da nesneyi ve referans sayısını tek bir tahsis içinde tahsis eden boost :: make_shared (tercihim) özelliğini kullanabilir, böylece çoğu önbellek sorununu gideririz. En yüksek seviyede nesneye bir referans tutarak ve nesneye doğrudan referanslar geçirerek, referans sayısını performans kritik kodunda güncellemenin performans vuruşunu önleyebilirsiniz.
Paylaşılan sahipliğe ihtiyacınız varsa ancak referans sayma veya çöp toplama maliyetini ödemek istemiyorsanız, değişmez nesneler veya yazma deyiminde bir kopya kullanmayı düşünün.
En yüksek performans kazanımlarınızın uzağa ve uzağa bir mimaride, ardından bir algoritma düzeyinde olacağına ve bu düşük seviyeli endişelerin çok önemli olmasına rağmen, sadece önemli sorunları ele aldıktan sonra ele alınmaları gerektiğini unutmayın. Önbellek özü düzeyindeki performans sorunlarıyla uğraşıyorsanız, söz konusu başına göstericilerle hiçbir ilgisi olmayan, aynı şekilde sahte paylaşımın farkında olmanız gereken birçok konunuz vardır.
Akıllı işaretçileri yalnızca dokular veya modeller gibi kaynakları paylaşmak için kullanıyorsanız, Boost.Flyweight gibi daha özel bir kütüphaneyi düşünün.
Yeni standart kabul edildiğinde, semantiği hareket ettirin, referansları değerleyin ve mükemmel iletme pahalı nesnelerle ve konteynerlerle çalışmayı çok daha kolay ve verimli hale getirecek. O zamana kadar işaretçileri, auto_ptr veya unique_ptr gibi yıkıcı kopya semantiklerine sahip bir Konteynerde (standart konsept) saklamayın. Boost.Pointer Container kitaplığını kullanmayı veya paylaşılan sahiplik akıllı işaretçilerini Konteynerler'de depolamayı düşünün. Performans kritik kodunda, her ikisinden de kaçınmayı Boost.Intrusive gibi izinsiz konteynerlerden yana düşünebilirsiniz.
Hedef platform kararınızı gerçekten fazla etkilememeli. Gömülü cihazlar, akıllı telefonlar, aptal telefonlar, PC'ler ve konsollar tüm kodu çalıştırabilir. Sıkı bellek bütçeleri ya da yükleme sonrasında / sonrasında dinamik ayırma olmaması gibi proje gereksinimleri daha geçerli kaygılardır ve seçimlerinizi etkilemelidir.
C ++ 0x kullanıyorsanız, kullanın std::unique_ptr<T>.
Tepegöz std::shared_ptr<T>sayısının referans sayma sayısının aksine, performans ek yükü yoktur . Bir benzersiz_ptr imlecine sahiptir ve sahipliğini C ++ 0x hareket anlamıyla aktarabilirsiniz . Onları kopyalayamazsınız - yalnızca taşıyın.
Ayrıca, örneğin std::vector<std::unique_ptr<T>>ikili uyumlu olan ve performansla aynı olan std::vector<T*>, ancak elemanları silerseniz veya vektörü temizlerseniz hafıza sızdırmaz. Bu aynı zamanda STL algoritmaları ile olduğundan daha iyi bir uyumluluğa sahiptir ptr_vector.
IMO birçok amaç için bu ideal bir konteynırdır: rasgele erişim, istisnai güvenli, bellek sızıntılarını önler, vektör yeniden tahsisi için düşük ek yük (sahnelerin arkasındaki işaretçilerin etrafındaki karıştırmalar). Birçok amaç için çok faydalı.
Hangi sınıfların hangi işaretçilere sahip olduğunu belgelemek iyi bir uygulamadır. Tercihen, normal nesneler kullanırsınız ve ne zaman istersen işaretçiler kullanmazsınız.
Ancak, kaynakları takip etmeniz gerektiğinde, işaretçileri geçmek tek seçenektir. Bazı durumlar var:
Bunun şu anda kaynaklarımı nasıl yönettiğimi kapsadığını düşünüyorum. Shared_ptr gibi bir göstericinin bellek maliyeti genellikle normal bir göstericinin bellek maliyetinin iki katıdır. Bu ek yükün çok büyük olduğunu düşünmüyorum, ancak kaynakları azsanız, akıllı işaretçilerin sayısını azaltmak için oyununuzu tasarlamayı düşünmelisiniz. Diğer durumlarda sadece yukarıdaki mermiler gibi iyi prensiplere göre tasarlarım ve profilci bana nerede daha fazla hıza ihtiyacım olacağını söyleyecek.
Özellikle işaretçilere destek olmak söz konusu olduğunda, uygulamaları tam olarak ihtiyacınız olan şey olmadıkça, bunlardan kaçınılması gerektiğini düşünüyorum. Başlangıçta beklenenden daha büyük bir maliyetle geliyorlar. Hafızanızın hayati ve önemli kısımlarını atlamanıza ve kaynak yönetimi yapmanıza izin veren bir arayüz sağlarlar.
Herhangi bir yazılım geliştirmeye gelince, verilerinizi düşünmenin önemli olduğunu düşünüyorum. Verilerinizin bellekte nasıl temsil edildiği çok önemlidir. Bunun nedeni, CPU hızının bellek erişim zamanından çok daha yüksek bir oranda artmasıdır. Bu genellikle bellek önbelleklerini çoğu modern bilgisayar oyununun ana darboğazı yapar. Verilerinizin erişim sırasına göre bellekte doğrusal olarak hizalanması önbellek için çok daha uygundur. Bu tür çözümler genellikle daha temiz tasarımlara, daha basit kodlara ve kesinlikle daha kolay hata ayıklama koduna neden olur. Akıllı işaretçiler kolayca kaynakların sık sık dinamik bellek ayırmalarına yol açar, bu da onların tüm belleğe dağılmalarına neden olur.
Bu erken bir optimizasyon değil, mümkün olan en erken zamanda alınabilecek ve alınması gereken sağlıklı bir karardır. Bu, yazılımınızın çalışacağı donanımı mimari olarak anlama meselesidir ve önemlidir.
Düzenleme: Paylaşılan işaretçilerin performansıyla ilgili dikkate alınması gereken birkaç şey vardır:
Her yerde akıllı işaretçiler kullanma eğilimindeyim. Bunun tamamen iyi bir fikir olup olmadığından emin değilim, ancak tembelim ve bazı C-tipi işaretçi aritmetik yapmak istemediğim hariç hiçbir dezavantajı göremiyorum. Boost :: shared_ptr kullanıyorum çünkü etrafına kopyalayabileceğimi biliyorum - eğer iki varlık bir görüntüyü paylaşıyorsa, biri ölürse diğeri de görüntüyü kaybetmemelidir.
Bunun dezavantajı, bir nesnenin işaret ettiği ve sahibi olduğu bir şeyi silmesi, ancak başka bir şeyin de onu işaret etmesidir, o zaman silinmez.
Ben yaşlıyım, oldskool ve bir bisiklet sayacı. Kendi işimde ham işaretçiler kullanıyorum ve çalışma zamanında dinamik tahsisler kullanmıyorum (havuzların kendisi hariç). Her şey bir araya toplanmış ve sahiplik çok katı ve asla devredilemez, gerçekten gerekirse özel bir küçük blok ayırıcı yazarım. Oyun sırasında her havuzun kendi kendini temizleyebileceği bir durum olduğundan eminim. İşler kıllı hale geldiğinde nesneleri tutamaçlara sardığım için onları yerlerine yerleştirebilirim, ama istemem. Konteynerler özel ve son derece çıplak kemiklerdir. Ayrıca kodu tekrar kullanmıyorum.
Tüm akıllı işaretçilerin, kapların ve yineleyicilerin erdemlerini asla tartışmasam da, ne olmasa da, son derece hızlı bir şekilde kodlayabildiğim için (ve makul derecede güvenilir) bilinir, ancak başkaları için bazı belirgin nedenlerle koduma atlamaları tavsiye edilmese de, kalp krizi ve sürekli kabuslar gibi).
İş yerinde, elbette, prototip oluşturmadığım sürece, çok şükrettiğim çok şey farklı.
Neredeyse hiçbiri bu kuşkusuz garip bir cevap olmasına rağmen ve muhtemelen herkes için uygun hiçbir yere yakın değildir.
Ancak, kişisel durumumda, belirli bir türün tüm örneklerini merkezi, rastgele erişimli bir dizide (iş parçacığı güvenli) ve bunun yerine 32 bitlik dizinlerle (göreceli adresler, vb.) Depolamayı çok daha faydalı buldum. mutlak işaretçiler yerine.
Başlangıç için:
Thiçbir zaman belleğe fazla dağılmamasını sağlar. Bu, düğümler işaretçiler yerine endeksler kullanılarak birbirine bağlanırsa, ağaçlar gibi bağlantılı yapıların arasında bile gezerken, her türlü erişim modeli için önbellek kayıplarını azaltma eğilimindedir.Bununla birlikte, kolaylık hem güvenli hem de tip emniyettir. Biz bir örneğini erişemiyor Terişimi kalmadan hem konteyner ve endeks. Eski düz bir kişi int32_tbize hangi veri türünden bahsettiği hakkında hiçbir şey söylemez, bu nedenle tür güvenliği yoktur. Yanlışlıkla Barbir dizin kullanarak bir erişmeyi deneyebiliriz Foo. İkinci sorunu hafifletmek için genellikle bu tür şeyler yapıyorum:
struct FooIndex
{
int32_t index;
};
Bu aptalca görünüyor ama bana tür güvenliğini geri veriyor, böylece insanlar yanlışlıkla bir derleyici Bararacılığıyla Foobir derleyici hatası olmadan erişmeyi deneyemezler . Rahatlık açısından, sadece hafif rahatsızlığı kabul ediyorum.
İnsanlar için büyük sıkıntı yaratabilecek başka bir şey de, OOP tarzı kalıtım temelli polimorfizmi kullanamamamdır, çünkü bu, farklı boyut ve hizalama gereklilikleri olan her türlü farklı alt tiplere işaret edebilecek bir temel işaretçi gerektirecektir. Ancak bugünlerde kalıtım çok fazla kullanmıyorum - ECS yaklaşımını tercih ediyorum.
Gelince shared_ptr, çok fazla kullanmamaya çalışıyorum. Bilmiyorum çoğu zaman mülkiyeti paylaşmanın bir anlamı yoktur ve bu yüzden dehşet verici bir şekilde yapmak mantıksal sızıntılara yol açabilir. Çoğu zaman en azından üst düzeyde, bir şey bir şeye ait olma eğilimindedir. Sık sık kullanmaya shared_ptrbaşladığım yerde, gerçekten sahiplikle fazla ilgilenmeyen yerlerdeki bir nesnenin ömrünü uzatmaktaydı, sadece iş parçacığı bitmeden önce nesnenin yok edilmemesini sağlamak için bir iş parçacığındaki yerel bir işlev gibi onu kullanarak.
Bu sorunun üstesinden gelmek için, shared_ptrGC veya bunun gibi bir şey kullanmak yerine, genellikle bir iş parçacığı havuzundan çalışan kısa ömürlü görevleri tercih ederim ve bu iş parçacığı bir nesneyi imha etmek isterse, gerçek imha güvenli bir şekilde ertelenir; sistemin, herhangi bir ipliğin bahsedilen nesne tipine erişmesi gerekmediğinden emin olabileceği süre.
Hala bazen ref-saymayı kullanıyorum ama son çare stratejisi gibi davranıyorum. Kalıcı bir veri yapısının uygulanması gibi mülkiyeti paylaşmanın gerçekten mantıklı olduğu birkaç durum var ve orada hemen ulaşmak için mükemmel bir anlam ifade ediyor shared_ptr.
Her neyse, çoğunlukla endeksleri kullanıyorum ve hem ham hem de akıllı göstergeleri az kullanıyorum. Nesnelerinizin bitişik olarak depolandığını ve hafıza alanı üzerine dağılmadığını bildiğiniz zaman açtıkları indeksleri ve kapı türlerini seviyorum.