Mengapa C ++ Game Developers tidak menggunakan boost library? [Tutup]

Jadi, jika Anda menghabiskan waktu melihat / menjawab pertanyaan tentang Stack Overflow di bawah tag C ++, Anda akan segera menyadari bahwa hampir semua orang menggunakan pustaka boost ; beberapa bahkan akan mengatakan bahwa jika Anda tidak menggunakannya, Anda tidak menulis "nyata 'C ++ (saya tidak setuju, tapi bukan itu intinya).

Tapi kemudian ada industri game, yang terkenal menggunakan C ++ dan tidak menggunakan boost. Saya bertanya-tanya mengapa itu terjadi. Saya tidak peduli menggunakan boost karena saya menulis game (sekarang) sebagai hobi, dan bagian dari hobi itu adalah mengimplementasikan apa yang saya butuhkan ketika saya bisa dan menggunakan perpustakaan di luar rak ketika saya tidak bisa. Tapi itu hanya aku.

Mengapa pengembang game tidak, secara umum, menggunakan perpustakaan boost? Apakah masalah kinerja atau memori? Gaya? Sesuatu yang lain

Saya hendak menanyakan ini pada stack overflow, tapi saya pikir pertanyaannya lebih baik ditanyakan di sini.

SUNTING :

Saya sadar saya tidak bisa berbicara untuk semua programmer game dan saya belum melihat semua proyek game, jadi saya tidak bisa mengatakan pengembang game tidak pernah menggunakan boost; ini hanyalah pengalaman saya.

Izinkan saya mengedit pertanyaan saya untuk juga bertanya, jika Anda menggunakan dorongan, mengapa Anda memilih untuk menggunakannya?

Beberapa pengembang melakukannya, beberapa pengembang tidak (dalam game dan di tempat lain). Itu tergantung pada apa kebutuhan / persyaratan pengembang tersebut, dan teknologi apa yang mereka miliki untuk mengungkitnya.

Perpustakaan standar C ++ 's sering diberikan perlakuan yang sama, dan orang-orang sering bertanya-tanya hal yang sama Anda bertanya-tanya tentang hal itu , juga. Sebagian besar alasannya serupa, misalnya:

• Pengembang mungkin sudah memiliki perpustakaan fungsionalitas in-house yang menyediakan layanan yang sama dengan yang disediakan oleh perpustakaan standar atau Peningkatan. Pustaka in-house seperti itu sering ditulis sejak lama, ketika dukungan implementasi untuk pustaka standar lemah dan Boost pada dasarnya tidak ada, sehingga mereka lebih-kurang harus ditulis. Dalam skenario ini, biasanya tidak benar-benar layak transisi dari fungsionalitas in-house - itu akan menjadi upaya porting besar yang akan membuat banyak kode tidak stabil, dan hampir tidak memberikan manfaat.

• Pengembang mungkin bekerja pada platform di mana dukungan kompiler untuk teknik C ++ lanjutan yang didukung oleh Boost tidak didukung dengan baik, sehingga kode Boost tidak dapat dikompilasi sama sekali atau berkinerja sangat buruk. Ini berlaku untuk perpustakaan standar juga, meskipun jauh lebih sedikit hari ini.

• Boost dan perpustakaan standar bahasa adalah tujuan umum, dan sementara itu bagus dan bagus untuk sebagian besar aplikasi, terkadang pengembang memiliki kebutuhan khusus yang dapat ditangani dengan lebih baik oleh wadah yang lebih khusus.

Saya pikir di atas adalah dua alasan yang masuk akal, walaupun pasti ada yang lain. Anda harus berhati-hati karena banyak alasan untuk menghindari Boost, perpustakaan standar, atau apa pun yang mengarah ke sindrom "tidak ditemukan di sini", yang dapat menjadi indikasi bahwa alasannya tidak terlalu beralasan dalam kenyataan praktis.

Juga ingat bahwa kebutuhan studio ish besar biasanya sangat berbeda dari kebutuhan pengembang individu. Misalnya, seorang pengembang perorangan mungkin memiliki lebih sedikit kode lawas yang mengambang untuk dipelihara dan mungkin porting dari versi Boost yang dikembangkan sendiri atau fungsi pustaka standar tidak akan sebesar waktu yang tersisa dan akan menyelamatkan pengembang itu dari keharusan mempertahankannya. kode itu sebagai ekstensif di masa depan - sehingga membatalkan poin pertama saya.

Pada akhirnya, ini semua tentang mengevaluasi kebutuhan Anda dan investasi waktu terhadap tujuan yang Anda inginkan dan menentukan opsi mana yang paling sesuai dengan kebutuhan Anda. Pengembang yang tidak menggunakan Boost atau perpustakaan standar biasanya melakukannya dan mencapai kesimpulan itu - mungkin Anda juga akan, dan mungkin tidak.

Sunting Kembali ke Pertanyaan Ini Setelah Beberapa Tahun
Setelah terus menggunakan lebih banyak dan lebih banyak perpustakaan, saya pikir saya akan memperbarui pertanyaan ini untuk memberikan alasan yang kuat mengapa Anda harus menggunakan peningkatan ketika deskripsi produk cocok dengan fungsionalitas yang Anda inginkan. Ini bahkan akan meyakinkan para penentang. Unduh openSSL, cobalah membuat aplikasi klien dan server dengannya. Sekarang coba dan buat itu bekerja di setiap platform. Kemudian, unduh dan gunakan boost :: asio :: ssl untuk membuat aplikasi yang sama. Jika Anda tidak yakin bahwa peningkatan adalah tempat yang tepat untuk mencari kode lintas-platform yang bersih, dioptimalkan dengan baik, ditinjau sejawat, latihan sederhana ini akan mengubah Anda.

Tl; versi dr:

Menurut pendapat saya, Anda tidak melihat satu ton pun perusahaan pengembangan indie atau kecil hingga menengah yang menggunakan boost karena itu adalah binatang buas besar dan kuat yang tidak mudah dijinakkan dan Anda pada dasarnya sendiri saat mencoba mempelajari cara untuk menggunakannya. Dokumentasi kurang dalam beberapa cara (lihat versi lama) dan "komunitas" di sekitar proyek entah itu hilang, tersebar atau tidak aktif (dibandingkan dengan proyek lain).

Very Long Winded Version:

Saya menyadari sudah ada jawaban yang diterima tetapi sebagai seseorang yang benar-benar menggunakan dorongan di hampir setiap proyek yang saya lakukan, saya pikir saya akan mengirim jawaban.

Saya ingat ketika saya pertama kali mencari-cari dorongan dan jujur ​​saya tidak tahu apa yang terjadi. Boost tidak didokumentasikan dengan baik sama sekali. Orang mungkin tidak setuju dengan saya karena saya yakin karena ada banyak potongan kode contoh dan komentar dan semacamnya, tetapi semuanya sangat dingin dan tidak jelas serta sulit dinavigasi.

Tampaknya juga sulit untuk menemukan tempat di mana Anda merasa telah menemukan "komunitas" di sekitar proyek. Kenyataannya komunitas itu tampaknya tidak ada, atau nomaden. Sayangnya, bahkan milis mereka telah dikendalikan oleh begitu banyak situs lintah sehingga Anda bisa turun ke lubang kelinci ini dan selalu kembali ke tempat Anda memulai.

Kedua faktor ini menjadikan belajar menggunakan perpustakaan pendorong merupakan tugas yang agak menakutkan. Sekalipun teknis penggunaan dorongan tidak terlalu rumit, itu adalah kumpulan besar perpustakaan dan menatapnya ketika semua yang Anda miliki hanyalah beberapa cuplikan kode dan potongan milis yang tersebar di sudut-sudut tergelap internet. ... baik Anda mendapatkan ide.

Saya mulai bermain-main dengan peningkatan sekitar versi 1.45 dan hanya sekarang dalam versi 1.52 / 1.53 saya merasa cukup nyaman untuk menggunakannya dalam produksi. Ada begitu banyak hal untuk dibiasakan dan diingat, bahkan hal-hal sederhana seperti bagaimana Anda telah mengonfigurasi peningkatan dan mengingat konfigurasi itu, karena bagaimana perpustakaan dibangun dan fungsinya dapat sangat bervariasi berdasarkan pada preferensi Anda pada waktu kompilasi karena bagaimana hal-hal yang dapat disesuaikan adalah.

Namun , jangan salah , begitu Anda dapat menggunakan boost, Anda telah mendapatkan senjata yang kuat untuk membangun program lintas platform yang solid dengan cepat. Ambil saja boost::asiocontohnya. Anda dapat menulis server web asinkron yang sangat kuat, dapat diskalakan, dan kokoh, hanya dalam beberapa ratus baris. Saya telah menulis banyak klien, server, proksi dll selama bertahun-tahun hanya dengan beberapa ratus baris kode yang masing-masing belum membuat saya gagal, dan dapat memindahkan mereka dari platform ke platform dalam hitungan menit.

Seperti yang ditunjukkan orang lain, perusahaan besar biasanya terjebak dengan barang warisan atau suka menggulung sendiri yang benar-benar saya pahami. Ada juga hal yang sangat konyol yang pernah saya dengar dan temui di mana dev memimpin dan atau manajer proyek melarang menggunakan dorongan karena itu "terlalu besar". Dugaan saya adalah bahwa mereka percaya bahwa peningkatan adalah 1 perpustakaan tunggal atau mereka belum pernah mendengar tentang BCP .

Adapun MENGAPA saya memilih untuk menggunakan boost

Saya akan mengatakan saya menggunakannya karena seperti yang Anda maksudkan dalam pertanyaan Anda, itu adalah "the" C ++ library. Boost dipandang di dunia C ++ sebagai pisau tentara swiss dari hal-hal yang pada akhirnya perlu Anda gunakan. Jadi idenya adalah bahwa jika ada kebutuhan, harus ada versi yang sangat berkinerja tinggi dan portabel. Perusahaan-perusahaan besar berkontribusi untuk meningkatkan , orang-orang yang sangat berpendidikan dengan resume yang mengesankan berkontribusi dan memeliharanya , dan ketika standar baru C ++ sedang dikembangkan, orang-orang biasanya ingin meningkatkan untuk melihat bagian mana yang harus menjadi standar C ++ ISO.

Jadi jika saya perlu menambahkan beberapa fungsionalitas yang mungkin ada untuk pustaka yang ada, tempat pertama yang akan saya lihat adalah meningkatkan hanya karena saya cukup aman dalam bertaruh bahwa itu dioptimalkan dengan baik, portabel, itu akan didukung dan dikelola untuk waktu yang sangat lama dan bug akan ditemukan dan ditangani. Di dunia open source kualitas-kualitas itu bisa sangat sulit didapat.

Kami menggunakan sedikit Boost kembali di tempat kerja lama kami. Alasan utama sebagian besar menghindarinya dan membatasi penggunaannya adalah:

• waktu kompilasi - beberapa di antaranya sangat lambat untuk dikompilasi, dan Anda akhirnya enggan untuk meningkatkan #termasuk dalam sembarang header Anda
• kompleksitas - tidak diketahui oleh sebagian besar pengembang game dan karenanya membuat kode yang tidak dapat dibaca
• kinerja - beberapa konsep berkinerja lambat secara default, misalnya. shared_ptr

Hal yang sama adalah (apakah?) Dikatakan untuk STL "lebih standar". Artikel ini membahas tentang EASTL, penulisan ulang in-house dari (bagian-bagian) STL oleh Electronic Arts untuk mengakomodasi kebutuhan pengembangan game yang agak berbeda dari pada pengembangan aplikasi "lebih umum".

Jadi, mungkin, seseorang di suatu tempat sedang menulis ulang (bagian dari) dorongan untuk mengakomodasi kebutuhan mereka dalam pengembangan game!

Siapa bilang mereka tidak menggunakan boost? Saya tahu satu atau dua mesin C ++ yang menggunakan boost. Saya tidak pernah secara langsung bekerja dengan mereka; tetapi, itu sebagian besar karena pengalaman saya terletak pada Unreal.

Adapun alasan yang saya temui untuk tidak menggunakan dorongan, dan ini subjektif:

• Kami suka menggulirkan struktur data kami sendiri yang spesifik ke platform yang kami gunakan
• Kami suka membatasi jumlah kode yang dikembangkan secara non-internal yang harus kami gunakan dalam proyek-proyek kami, terutama ketika kode eksternal itu bergantung pada perpustakaan lain yang dikembangkan secara eksternal.

Ini pada dasarnya bermuara pada: solusi umum tidak selalu "pas."

Saya yakin seseorang yang benar-benar bekerja dengan perpustakaan dapat berkomentar lebih baik.

Saya hang out di StackOverflow dan tidak menggunakan boost. Saya akan menambahkan alasan saya, karena itu belum disebutkan.

Boost punya banyak ide bagus, sungguh. Saya suka melihat apa yang telah mereka lakukan dan mencoba hal-hal dan ide-ide baru. Mereka hebat, karena merupakan tempat berkembang biak bagi banyak perbaikan C ++.

Tetapi dorongan itu adalah binatang yang sangat berat karena banyak alasan. Salah satu alasannya adalah bahwa mereka perlu (ingin) agar kompatibel pada hampir semua kompiler dengan kebiasaan apa pun. Akibatnya mereka perlu menggunakan banyak trik, seperti MPL untuk melakukannya. Sebagai contoh (dahulu kala) saya ingin menggunakan shared_ptr mereka, menjalankannya berarti saya membutuhkan sumber dan pustaka yang terasa seperti 90% peningkatan. Saya akhirnya menulis sendiri; 50 baris kode yang dapat dibaca. (Persyaratan saya di mana lebih ketat, seperti tidak ada lemah_ptr atau keamanan utas.)

Seringkali Anda membutuhkan subset boost yang sangat kecil, tetapi memadukan keseluruhan boost tidak sepadan dengan kerumitannya.

Edit :

Hanya untuk memperjelas, karena tampaknya tidak datang dengan jelas (yaitu downvote). Saya menggunakan jangan menggunakan pihak ketiga perpustakaan. Tetapi dalam kebanyakan kasus, semua hal sama, mengintegrasikan perpustakaan pihak ketiga atau meningkatkan, perpustakaan pihak ketiga lainnya lebih cepat dan lebih bersih. Sisanya dilakukan dalam latihan jari "2j". Saya sangat teliti dalam membangunnya atau membeli pertanyaan.

Dalam kasus kami (bukan game), kami memiliki alasan kuat untuk tidak menggunakan boost (atau std): Kami memiliki banyak kode yang berasal dari satu dekade yang lalu. Menurut para senior, std dan boost tidak lengkap, penuh bug atau terlalu lambat untuk hal-hal berkinerja tinggi yang kami butuhkan. Jadi beberapa kelas dasar diimplementasikan, menggunakan konsep yang sama (seperti iterator) dan sering dioptimalkan untuk algoritma kami. Saat ini, ketiga perpustakaan (milik kami, std dan boost) sangat mirip.

Tetapi apakah kita ingin melakukan porting pada semua kode kita? Tidak juga. Saya berasumsi banyak perusahaan lain menghadapi dilema yang sama. Entah menulis ulang banyak kode yang diuji dan bekerja atau tidak menggunakan std / boost.

Saya pribadi tidak menggunakan dorongan atau kode tujuan umum lainnya saat membuat game, karena game pada umumnya bukan tujuan umum. Jenis kode yang Anda butuhkan untuk mengimplementasikan permainan biasanya khusus untuk pengembangan game, tidak selalu tetapi seperti 98% (angka acak) pada waktu itu. Anda dapat menempel pada beberapa bit kode terakhir dari boost atau lib lainnya, tetapi mungkin lebih baik hanya menuliskan bagian kecil yang Anda perlukan di sana-sini.

Di samping catatan, saya pikir itu agak menyenangkan untuk menulis kode Anda sendiri di c ++, itulah sebabnya saya tidak pernah menggunakan dorongan atau hal seperti itu.

warisan di perpustakaan rumah bukan merupakan faktor ... alasan utama mengapa orang tidak boleh menggunakan boost u perpustakaan tujuan umum lainnya adalah karena mereka tidak dioptimalkan kecepatan dan memori, sehingga saya harus menyebutkan bahwa Cryengine menggunakan STL tetapi mereka mengkompilasi itu lebih dari versi open source yang disebut STLPort, jadi jangan takut menggunakan STL, cukup implementasikan pengalokasi kustom Anda dan Anda akan baik-baik saja. jangan gunakan boost tho.