Neden C ++ Game Developers bu destek kütüphanesini kullanmıyor? [kapalı]


81

Bu nedenle , C ++ etiketi altındaki Stack Overflow ile ilgili soruları görüntülemek / cevaplamak için zaman harcıyorsanız , hemen hemen herkesin yükseltme kitaplığını kullandığını hemen fark edeceksiniz ; Hatta bazıları bunu kullanmazsanız, "real 'C ++ yazmıyorsunuzdur (katılmıyorum, ama mesele bu değil).

Ancak, C ++ kullanmasıyla bilinen ve hızlandırma yapmayan oyun endüstrisi var . Yardım edemem ama bunun neden olduğunu merak ediyorum. Takviye kullanmak umrumda değil çünkü oyunlar (şimdi) bir hobi olarak oyunlar yazıyorum ve bu hobinin bir kısmı da yapamadığım zamanlarda ihtiyaç duyduğum şeyi uyguluyor ve yapamadığım zamanlarda kullanıma hazır kütüphaneleri kullanıyor. Ama bu sadece benim.

Oyun geliştiricileri neden genel olarak destek kütüphanesini kullanmıyor? Performans mı, bellek kaygıları mı? Stil? Başka bir şey?

Bunu yığın taşması üzerine sormak üzereydim, ancak sorunun burada daha iyi sorulabileceğini düşündüm.

DÜZENLE :

Tüm oyun programcıları için konuşamayacağımı ve tüm oyun projelerini göremediğimi farkettim, bu yüzden oyun geliştiricilerin asla destek kullanmayacağını söyleyemem ; bu sadece benim deneyimim.

Ayrıca, soruyu düzenlememe izin verin, eğer destek kullanıyorsanız, neden kullanmayı seçtiniz?



2
"Yükseltme" nin, "artırma kullanımı" veya "artırma kullanma" yı adil bir seçim haline getirmek için çok büyük bir kütüphaneler koleksiyonu olduğunu söylemek doğru olmaz mıydı? Hatta Google bile standartlarında küçük bir "artırma" alt grubuyla sınırlı olduğunu düşünüyorum.
Dan Olson,

Oyun ikili dosyaları zaten yeterince büyük.
Legion

3
@Tetrad STL artmaz ve STL gamedev'de yoğun olarak kullanılır.
rootlocus

7
Sorunun "yapıcı değil" olduğunu gerçekten görmüyorum, bunun açıklamaya ihtiyacı var.
v.oddou

Yanıtlar:


42

Bazı geliştiriciler yapar, bazı geliştiriciler yapmaz (oyunlarda ve başka yerlerde). Bu, geliştiricilerin ihtiyaçlarının / gereksinimlerinin ne olduğuna ve hangi mevcut teknolojiden yararlanmaları gerektiğine bağlıdır.

C ++ 'ın standart kütüphane genellikle aynı tedavi verilir ve insanlar sık sık merak ediyor aynı şeyi merak bunun da. Sebeplerin çoğu benzer, örneğin:

  • Bir geliştirici zaten standart kütüphanenin veya Boost'un sağladığı hizmetleri sağlayan kurum içi bir işlev kütüphanesine sahip olabilir. Böyle içi kütüphaneler, standart kütüphane için uygulama desteği zayıftı ve Boost temelde olmayan iken sık sık, uzun zaman önce yazılı, bu yüzden daha çok ya da daha az edildi vardı yazılacak. Bu senaryoda, genellikle kurum içi işlevsellikten uzaklaşmaya değmez - çoğu kodu dengesizleştirecek ve neredeyse hiçbir fayda sağlamayacak büyük bir taşıma çabası olacaktır.

  • Bir geliştirici, Boost'un kullandığı gelişmiş C ++ teknikleri için derleyici desteğinin iyi desteklenmediği, Boost kodunun hiç derlemediği veya oldukça düşük performans gösterdiği platformlarda çalışıyor olabilir. Bu, bugünlerde çok daha az olmasına rağmen, standart kütüphane için de geçerlidir.

  • Boost ve dilin standart kütüphanesi genel bir amaçtır ve çoğu uygulama için iyi ve güzel olsa da, bazen bir geliştiricinin daha özel kapsayıcılar tarafından daha iyi ele alınabilecek özel ihtiyaçları vardır.

Bence yukarıda belirtilenler makul iki neden, kesinlikle başkaları da var. Yine de dikkatli olmalısınız çünkü Boost, standart kütüphanelerden ya da "burada icat edilmemiş" sendromdan kaçınmak için neden pek çok nedenden kaynaklanıyor ki bu, sebebin pratik gerçeklerde çok iyi temele alınmadığının bir göstergesi olabilir .

Ayrıca, büyük bir iş stüdyosunun ihtiyaçlarının genellikle bireysel geliştiricilerin ihtiyaçlarından çok farklı olduğunu unutmayın. Örneğin, münferit bir geliştirici korumak için etrafta dolaşan daha az eski kodlara sahiptir ve Boost veya standart kütüphane işlevlerinin evde yetiştirilen bir sürümünden bahsetmek, zaman alıcı kadar büyük olmayacaktır ve bu geliştiricinin bakımını yapmak zorunda kalmasına neden olacaktır. Bu kod gelecekte geniş çapta olduğu gibi - ilk kurşun noktamı geçersiz kılıyordu.

Sonuçta, ihtiyaçlarınızı ve zaman yatırımınızı istediğiniz hedefe göre değerlendirmek ve hangi seçeneğin ihtiyaçlarınızı en iyi şekilde karşıladığını belirlemek ile ilgilidir. Boost'u veya standart kütüphaneyi kullanmayan geliştiriciler genellikle bunu yaptılar ve bu sonuca vardılar - belki siz de yapacaksınız, belki de değil.


2
Başka bir nokta - bazı şirketler yüksek düzeyde etkileşimli bir geliştirme ortamında derleme hızı üzerindeki olumsuz etkilerinden dolayı Boost kullanmıyor.
Steven

27

Düzenleme Birkaç Yıl Sonra Bu Soruya Geri Dönme
Daha fazla destek kütüphanesi kullanmaya devam ettikten sonra , ürünün açıklaması istediğiniz işlevsellikle eşleştiğinde neden destek kullanmanız gerektiğine dair sağlam bir durum vermek için bu soruyu güncelleyeceğimi düşündüm. Bu bile nay-söyleyenleri ikna edecektir. OpenSSL'yi indirin, onunla bir istemci ve sunucu uygulaması yapmaya çalışın. Şimdi her platformda bu işi yapmaya çalışın. Ardından, aynı uygulamayı yapmak için boost :: asio :: ssl dosyasını indirip kullanın. Yükseltmenin temiz, iyi optimize edilmiş, eşler arası gözden geçirilmiş, çapraz platform kodu aramak için doğru yer olduğuna inanmıyorsanız, bu basit alıştırma sizi dönüştürür.

Tl; dr sürümü:

Benim düşünceme göre, destek kullanan tonlarca indie ya da küçük ila orta boy geliştirme firması görmüyorsunuz, çünkü evcilleştirilmesi kolay olmayan muazzam ve güçlü bir vahşi hayvan; kullanmak için. Belgeler birkaç yönden yoksundur (uzun sürüme bakınız) ve proje etrafındaki “topluluk” ya eksik, dağınık veya etkin değil (diğer projelere kıyasla).

Çok Uzun Süreli Sürüm:

Şimdiden kabul edilmiş bir cevap olduğunu fark ettim; ancak yaptığım hemen hemen her projede destek kullanan biri olarak cevap göndereceğimi düşündüm.

Etrafta ilk kez dürtme ile düştüğümde ve ne olduğu hakkında hiçbir fikrim olmadığını hatırlıyorum. Destek, hiç iyi bir şekilde belgelenmemiş. İnsanlar emin değilim konusunda benimle aynı fikirde olmayabilir, çünkü bir sürü örnek kod parçacığı ve yorum gibi şeyler var, ancak gezinmesi çok zor ve belirsiz.

Ayrıca, proje çevresinde "topluluk" bulduğunuzu düşündüğünüz bir yer bulmak zor görünüyor. Aslında, topluluk varolmamış ya da göçebe görünüyor. Maalesef posta listeleri bile o kadar çok sülük bölgesi tarafından kontrol ediliyordu ki, bu tavşan deliğinden aşağıya inebiliyorsunuz.

Bu iki faktör, artırma kütüphanelerini kullanmayı öğrenmeyi göz korkutucu bir görev haline getirir. Desteği kullanma teknikleri aşırı derecede karmaşık olmasa bile, büyük bir kütüphane kümesidir ve silahlı olduğunuz her şey, bir kaç kod parçacığı ve posta listesinin internetin en karanlık köşelerinden dağılmış parçaları olduğunda aşağı bakıyor ... iyi fikir aldın.

1.45 sürümündeki destekle başa çıkmaya başladım ve yalnızca şu anda 1.52 / 1.53 sürümünde üretimde kullanmak için yeterince rahat hissediyorum. Alışılacak ve hatırlanacak çok şey var, nasıl yapılandırıldığınızı nasıl yapılandırdığınızı, nasıl yapılandırdığınızı nasıl arttıracağınız gibi basit şeyler bile, çünkü kütüphanelerin nasıl inşa edildiği ve nasıl işlediğinin nasıl özelleştirilebileceği nedeniyle derleme zamanında tercihlerinize göre çılgınca değişebilir vardır.

Ancak , hiçbir hata yapmayın , bir kez daha güçlenmeye devam ederseniz, sağlam, platformlar arası programları hızla oluşturmak için güçlü bir silah edindiniz. Sadece boost::asiomesela. Sadece birkaç yüz satırda son derece güçlü, ölçeklenebilir ve kaya gibi sağlam bir çapraz platform asenkron web sunucusu yazabilirsiniz. Yıllar geçtikçe birden fazla müşteri, sunucu, proxy vb. Her birini henüz başarısızlığa uğratmayan birkaç satırlık kod yazdım ve birkaç dakika içinde platformdan platforma taşıyabilirim.

Diğerlerinin de belirttiği gibi, daha büyük şirketler genellikle eski şeylere takılmış ya da tamamen anladığım kendi şirketlerini devirmeyi seviyorlar. Aynı zamanda duyduğum ve karşılaştığım, gerçekten çok aptalca bir şey var. Tahminime göre, artırmanın 1 tek kütüphane olduğuna inanıyorlar veya BCP'yi hiç duymamışlar .

NEDEN gelince ben boost kullanmayı tercih ediyorum

Bunu kullanacağımı söyleyebilirim çünkü sorunuzda olduğu gibi "C ++ kütüphanesi" dir. Boost, C ++ dünyasında, sonunda kullanmanız gereken şeylerin İsviçre çakısı olarak görülüyor. Bu nedenle fikir, bir ihtiyaç olması halinde, yüksek performans gösteren, yüksek performanslı ve taşınabilir bir versiyonunun olması gerektiğidir. Büyük şirketler artırılmasına katkıda bulunduğu , etkileyici özgeçmiş ile çok eğitimli insanlar katkıda bulunmak ve bunu korumak ve C ++ yeni bir standart geliştirilmektedir zaman, insanlar genellikle bazı bölümleri ++ ISO standart C olması gerektiğini görmek için artırmak için bekliyoruz.

Bu nedenle, muhtemelen var olan bir kütüphanenin var olduğu bazı işlevler eklemem gerekirse, bakacağım ilk yer, sadece iyi bir şekilde optimize edilmiş, taşınabilir olduğuna dair bahis konusunda oldukça güvende olduğum için artıracağım. çok uzun bir süre ve böcekler bulunacak ve ele alınacaktır. Açık kaynak dünyasında bu niteliklerin ortaya çıkması çok zor olabilir.


Belgelendirme için çok doğru. Örneğin, Boost.asio doc'sı şaşırtıcı bir şekilde birkaç satırda bir http sunucusunun nasıl yazılacağını açıklayacaktır; oyununuz http (ya da bu konuda başka herhangi bir vanilya TCP protokolü kullanıyorsa), ancak kullanmak çok daha zor hale gelir özel bir protokol veya tescilli ağ kütüphanesi. Boost.asio kullanarak nasıl bir websocket sunucusu oluşturduğumu anlamam 20 dakika sürdü, ancak ENet ( enet.bespin.org ) 'u özel bir boost.asio io_service üzerinden nasıl kullanacağımı anlamak haftalar sürdü.
ClosetGeek 13:14

21

Eski iş yerimizde bir miktar Boost kullandık. Bundan kaçınmanın ve kullanımını sınırlamanın temel nedenleri şunlardı:

  • derleme zamanları - bir kısmı derlemek için çok yavaştır ve üstbilgilerinizden herhangi birinde # içindekileri artırmak için isteksiz olursunuz
  • karmaşıklık - çoğu oyun geliştiricisi tarafından iyi bilinmez ve bu nedenle okunamayan kodları oluşturur
  • performans - bazı kavramlar varsayılan olarak yavaş çalışır. shared_ptr

1
artırmak :: shared_ptr? nasıl yani?
Tili

6
Doğru hatırlıyorsam, yığıntaki referans sayısını bir yere tahsis eder. Bu, kullanım sırasında önbellek tutarlılığı için çok kötüdür ve aynı zamanda başlangıç ​​ve bitiş zamanlarındaki tahsisat ve tahsisat süresi iki katına çıkar.
Kylotan

10
(Make_shared kullanımının bu sorunu gidermeye değer olduğu sorusu hafifletebilir.)
Kylotan

Bence bu cevap, insanların bir ya da iki kötü dersten kaçmaktan kaçınmasının daha fazla sebebi olduğu oldukça açık.
Kylotan

16

Aynı şey (?) "Daha standart" STL için de söyleniyor. Bu makale , EASTL hakkında, elektronik sanatlar tarafından STL'nin "bölümlerinin" yeniden yazılması olan ve "daha genel" uygulama geliştirmeden çok farklı olan oyun geliştirme gereksinimlerini karşılamak üzere yazılmıştır.

Yani, belki de bir yerlerde birileri yeniden oyun yazıyor (bölümlerinin bir kısmı) oyun geliştirmedeki ihtiyaçlarını karşılamak için destek veriyor!


Makale için +1. Bence bu soruyu çok güzel cevaplıyor.
egarcia

9
Tecrübelerime göre kod tabanınız ne kadar taşınabilir hale gelirse, o kadar STL gibi "standart" bileşenleri yeniden yazıyorsunuz.
Jari Komppa

6

Takviye kullanmadıklarını kim söyledi? Takviye kullanan bir veya iki C ++ motoru tanıdım. Hiçbir zaman doğrudan onlarla çalışmadım; ama, bu çoğunlukla benim deneyimim Unreal'da olduğu için.

Takviye kullanmadığım için karşılaştığım nedenlerle ilgili olarak bunlar özneldir:

  • Dağıtımını yaptığımız platformlara özel kendi veri yapılarımızı yuvarlamaktan hoşlanıyoruz
  • Projelerimizde kullanmak zorunda olduğumuz dahili olmayan gelişmiş kodların miktarını sınırlamayı seviyoruz, özellikle bu harici kod harici olarak geliştirilen diğer kütüphanelere bağlıysa.

Temel olarak aşağı kayıyor: genel bir çözüm her zaman "doğru uygun" değildir.

Eminim kütüphanede çalışan biri daha iyi yorum yapabilir.


Doğru, bunu hesaba katmak için sorumu düzenledi.
James,

5

StackOverflow'ta takılıyorum ve boost kullanmıyorum. Sebebimi ekleyeceğim, çünkü henüz bahsedilmedi.

Boost'un gerçekten harika fikirleri var. Ne yaptıklarına bakmayı ve yeni şeyler ve fikirler denemeyi seviyorum. Harikalar, çünkü birçok C ++ iyileştirmesi için üreme alanı.

Fakat bu destek birçok nedenden ötürü çok hantal bir canavar. Sebeplerden biri, neredeyse herhangi bir tuhaflıkla herhangi bir derleyicide uyumlu olmaları gerekmesidir (istemek). Sonuç olarak, MPL gibi birçok numarayı kullanmaları gerekir. Örneğin (uzun zaman önce) onların paylaşılan ptr'lerini kullanmak istedim, çalışmasını sağlamak demek,% 90'lık artış hissi veren kaynaklara ve kütüphanelere ihtiyacım olduğu anlamına geliyor. Ben kendim yazdım; 50 okunabilir kod satırı. (Daha katı olan gereksinimlerim, zayıf_ptr veya iş parçacığı güvenliği gibi değil.)

Genellikle, gerçekten küçük bir destek alt kümesine ihtiyaç duyarsınız, ancak destek tümünün bütünleştirilmesi uğraşmaya değmez.

Düzenle :

Sadece yapmak açıktır, çünkü açıkça anlaşılmamış gibi görünmektedir (yani aşağı oy). Kullandığım do üçüncü parti kütüphaneleri kullanın. Ancak çoğu durumda, her şey eşit olmak, bir üçüncü taraf kütüphanesini entegre etmek veya artırmak, diğer üçüncü taraf kütüphanesi daha hızlı ve daha temizdir. Kalan "2 saat" parmak egzersizinde yapılır. İnşa etmeyin ya da soru alın.


1
BCP gibi araçlar var, bilirsin.
Bartek Banachewicz

2
Kendi kodunuzu korumanızın gerekmediğini mi ima ediyorsunuz? Ayrıca, 2 saat içinde kullanacağım tüm destek parçalarını 2 saat içinde yazabilmemin iyi olmasını diliyorum (bu, onları kullanacağım tüm yapı hedeflerinde test etmeyi ve test yazmayı da içerir). Gerçekten hızlı bir kodlayıcı olmalısın. Ah, ayrıca "faydalı bitlerin çoğu" hemen hemen burada "C ++ yapamıyorum" a eşittir, çünkü standart hala çok fazla .
Bartek Banachewicz

2
Başlangıç ​​olarak, artırmayla sağlanan birkaç özellik için, başka bir yerde küçük iyi tanımlanmış paketlerde buldum, örneğin sigc ++. Çoğu durumda daha şık ve / veya daha verimli. İplikler, akıllı işaretçiler ve düzenli ifadeler gibi özellikleri standart hale getiren şeyler gibi birçok özelliği arttırmaya geldim. Yıllar boyunca üçüncü taraf kütüphanelerden oluşan bir koleksiyon ve kendi kodumu edindim. 15 yıldan fazla bir süredir "C ++ yapabilirim", çok teşekkür ederim.
rioki

3
@SeanFarrell küçümsememelisin. 15 yıldan beri C ++ yaptığını söylüyorsun ve sonra Bartek’in alaycı bir alaycı yorumunda, Bartek’in “paketler” ile “koru” dediği zaman ne anlama geldiğini anlamıyor gibisin. Bakım yapmak onları düzeltmek anlamına gelmez. Yeni bir sürümde güncellemek veya sürümleri birden çok hedef için saklamak genellikle bunun anlamıdır. Sadece FYI.

3
Sigh Boost ayrıca kutunun dışında da çalışır, ama yine de onu korumasından bahsettin. Mantığınızı burada göremiyorum.
Bartek Banachewicz

4

Bizim durumumuzda (oyun değil), artırma (ya da std) kullanmamak için harika bir nedenimiz var: On yıl öncesine dayanan çok fazla kodumuz var. Yaşlılara göre, std ve boost ya eksik, böcek dolu ya da ihtiyaç duyduğumuz yüksek performanslı şeyler için çok yavaştı. Böylece bazı temel sınıflar aynı kavramları kullanarak (yineleyiciler gibi) uygulandı ve algoritmalarımız için sıklıkla optimize edildi. Günümüzde üç kütüphanenin tümü (bizim, std ve boost) birbirine çok benziyor.

Fakat tüm kodumuzu taşımak istiyor muyuz? Pek sayılmaz. Diğer iki şirketin de aynı ikilemle karşı karşıya olduğunu varsayıyorum. Test edilmiş ve çalışan kodların çoğunu yeniden yazın veya std / boost kullanmayın.


5
Bu doğrudur ve aklıma gelmeyen bir şeydi, ancak C ++ 'ta oyun geliştirmeye başlayan birçok insanın boost / std kullanmak istemediğini fark ettim. Bazen bunu hissediyorum çünkü öğrenme artışı yepyeni bir dil öğrenmek gibidir.
James,

1
@James Bu hemen hemen en büyük sebeplerden biri. Ben sadece bir destek yolundayken, sadece destekleme yolunda öğrenmeye devam eden biri olarak bakış açımı vermek için bir bakış açısı kabul ettiniz, ancak ondan kaçmak için cazip davrandıktan sonra değil.

1

Oyun yaparken genel olarak desteklemediğim için, oyun yaparken şahsen destek ya da genel amaçlı başka bir kod kullanmıyorum. Bir oyunu uygulamak için ihtiyaç duyacağınız kod türü, genellikle zaman zaman% 98'inden (rastgele rakam) değil oyun gelişimine özgüdür. Yükseltme veya başka bir lib'in son birkaç kod parçasını çözebilirsiniz, ancak burada ve oraya ihtiyacınız olan küçük parçayı yazmak muhtemelen daha iyidir.

Bir yandan, kendi kodunuzu c ++ 'da yazmanın oldukça eğlenceli olduğunu düşünüyorum, bu yüzden hiçbir zaman destek ya da onun gibi bir şey kullanmıyorum.


3
Bu eğlenceli, ancak destek, tekerleği yeniden icat etmek yerine, sh * t yapmak isteyen insanlar içindir.
Bartek Banachewicz

3
Bu benim görüşüme göre, ancak “oyunların özel olduğunu” söylemek yanıltıcıdır. Evet, gerçek zamanlı endüstri otomasyonu da özeldir. İkisini de yapıyorum ve artırmanın uygulanacağı bitlerin çok net bir şekilde benzer olduğunu itiraf ediyorum. Farklı olduklarını söylemek cehalettir, çünkü saçaklarda çok farklılar ancak ana dil kullanımı aynıdır. Bir sıralama işlevi, temelde ne sıraladığınızın önemi yoktur. (Sonra tekrar, sadece bunu yapabilirsiniz, demek isteyeceksiniz anlamına gelmez, cevabımı görün.)
rioki

2
Tüm network / multiplayer katmanını boost :: asio kullanarak oyununuza ekleyebilir ve bunun için kendi iletişim protokolünüzü icat edebilirsiniz. Bu,% 100 mükemmel bir geçerli destek nedenidir, bu, şimdiye kadar herhangi bir ağla ilgili işlev gerektiren herhangi bir oyunda yazdığınız oyunlardır. Yeniyken ve öğrenmeniz gerektiğinde "kendi yuvarlanma" harika olabilir. Bunda yanlış bir şey yok. Ancak günün sonunda, zaten bittiğinde ve bu konuda iyi bir şekilde kendi çapraz platform asenkron iletişim katmanımı yazmaya çalışmakla zaman kaybetmeyeceğim.

2
@HaywireSpark İnsanlara hakaret etmeye başlamanıza gerek yok. Görevinizi okudum ve hala size katılmıyorum. "Genelde belirli" ile gitmiş olsanız bile, bu tamamen alakasızdır. Hemen hemen her şey destek için mümkün olduğunca taşınabilir ve değişken olacak şekilde tasarlanmıştır. boost :: asio çok genel bir uygulamadır ve herhangi bir ağ iletişimi yoluna yönelik değildir. "Gee, boost :: asio ağ oluşturma katmanımın modeline uymuyor, tekerleği daha iyi yeniden icat ettim" demek zorunda olduğum hiçbir senaryoyu hayal edemiyorum. Sadece söylüyorum.

2
@HaywireSpark sigh. İyi günler dostum. Eleştiriye daha açık olmaya çalışmalısın. Eleştiriyi kabul edebilmek öğretilebilir olmanın bir parçasıdır ve eğer öğretilemezseniz asla bir şey öğrenemezsiniz. Seni seçmiyorum. Yorumunuzu yayınlayan her kişi sizinle aynı fikirde değil. Bu genellikle, uygunsuz bir şey söylediğinizi gösteren iyi bir göstergedir.

0

ev kütüphanelerindeki miras bir faktör değildir ... başka bir genel amaçlı kütüphane için başkalarının kullanmamasının temel nedeni, hız ve hafızayı optimize etmemeleridir; STLPort adlı açık kaynak kodlu bir sürümde çalışıyor, bu yüzden STL'yi kullanmaktan korkmayın, sadece özel tahsisatçılarınızı uygulayın; tho artırmak kullanmayın.


5
-1: "Boost" un "optimize edilmiş hız ve hafızanın" olmadığı inancına göre, kelimenin tam anlamıyla onlarca farklı hız ve hafıza verimliliğine sahip düzinelerce Boost kütüphanesi var.
Nicol Bolas,

2
... Aslında , bir dizi oyun geliştiricisinin, ağır şablon kullanımının çatıdan süreleri derlemesiyle birlikte kendi STL'lerini artırmaktan ve hatta yuvarlamaktan kaçınmasının nedeni budur. Özellikle MSVC üzerine kurulmuş hata ayıklama işlemlerini gerçekleştirin; burada, kaçınabilecek mutlak minimum soyutlama, sarmalayıcılar ve jenerikliğe ihtiyaç duyarsınız. Sorun algoritmik değildir, ancak Boost'un asla metal devriyle ilgili olmadığı anlamına gelir. Oyun geliştiricilerin dışında kimse, yine de gerektiren takaslar istemez.
Sean Middleditch

2
@seanmiddleditch: Demek istediğim Boost'ta çok sayıda kütüphane var . Bazıları aynı işi yapmak için kodlayabileceğiniz her şeyden daha hızlı ve daha verimlidir, ancak bazıları değildir. Bunun için bütün kütüphaneleri inkar etmek basitçe cahildir.
Nicol Bolas

2
Boost.Spirit'ten daha hızlı bir ayrıştırıcı yazabilecek birçok oyun geliştiricisi yoktur. Tam dilleri ayrıştırmak için daha iyi (kullanımı kolay) seçenekler olsa da, Spirit, iyi yapılandırılmış dizeleri ayrıştırmada çok hızlıdır, hatta sadece dizeleri veri türlerine dönüştürür. Boost.Xpressive kütüphanesi ayrıca regex için çok hızlı. Boost üzerinde çalışan insanların çoğunun C ++ standart komitesinde çalışan insanlar olduğunu ve platformlarda C ++ 'dan en iyi performansı nasıl elde edeceklerini bildiklerini unutmayın.
Gerald

5
Sık sık şablon metaprogramlamasını, çalışma zamanının yerine derleme zamanında yapılmasına izin verecek şekilde kullanırlar; . Boost muadillerini kullanmak için bazı genel yüksek performanslı C kitaplıklarından bazı görevleri dönüştürürken 50x'in üzerinde performans artışı gördüm.
Gerald
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.