C ++ गेम डेवलपर्स डेवलपर लाइब्रेरी का उपयोग क्यों नहीं करते हैं? [बन्द है]


81

इसलिए यदि आप C ++ टैग के तहत स्टैक ओवरफ्लो पर किसी भी समय देखने / जवाब देने में समय बिताते हैं , तो आप जल्दी से ध्यान देंगे कि सभी के बारे में बूस्ट लाइब्रेरी का उपयोग करता है ; कुछ तो यह भी कहेंगे कि यदि आप इसका उपयोग नहीं कर रहे हैं, तो आप "वास्तविक 'सी ++ नहीं लिख रहे हैं (मैं असहमत हूं, लेकिन यह बात नहीं है)।

लेकिन फिर गेम इंडस्ट्री है, जो C ++ का उपयोग करने और बढ़ावा का उपयोग नहीं करने के लिए अच्छी तरह से जानी जाती है । मैं मदद नहीं कर सकता, लेकिन आश्चर्य है कि ऐसा क्यों है। मुझे बूस्ट के रूप में गेम (अब) लिखने के कारण बूस्ट का उपयोग करने की परवाह नहीं है, और जब मैं नहीं कर सकता तो मैं ऑफ-द-शेल्फ लाइब्रेरी का उपयोग करने में सक्षम हूं और उस शौक का हिस्सा लागू कर रहा हूं। लेकिन वह मैं ही हूं।

खेल डेवलपर्स, सामान्य रूप से, बूस्ट लाइब्रेरी का उपयोग क्यों नहीं करते हैं? क्या यह प्रदर्शन या स्मृति चिंता है? अंदाज? कुछ और?

मैं स्टैक ओवरफ्लो पर यह पूछने वाला था, लेकिन मुझे लगा कि यह सवाल यहां बेहतर है।

संपादित करें:

मुझे लगता है कि मैं सभी गेम प्रोग्रामर के लिए बात नहीं कर सकता हूं और मैंने सभी गेम प्रोजेक्ट नहीं देखे हैं, इसलिए मैं यह नहीं कह सकता कि गेम डेवलपर्स कभी भी बूस्ट का उपयोग नहीं करते हैं; यह केवल मेरा अनुभव है।

मुझे अपना प्रश्न संपादित करने की अनुमति भी दें, यदि आप बूस्ट का उपयोग करते हैं, तो आपने इसका उपयोग करने का विकल्प क्यों चुना?



2
क्या यह कहना उचित होगा कि "बूस्ट" "उपयोग बूस्ट" या "बूस्ट का उपयोग न करें" उचित विकल्प बनाने के लिए पुस्तकालयों का एक संग्रह है? यहां तक ​​कि Google उनके मानकों में "बढ़ावा" के एक छोटे से हिस्से को प्रतिबंधित करता है, जो मुझे विश्वास है।
डैन ओल्सन

गेम बायनेरी पहले से ही काफी बड़े पैमाने पर हैं।
लीजन

3
@ टेट्राद एसटीएल को बढ़ावा नहीं है, और एसटीएल भारी रूप से gamedev में उपयोग किया जाता है।
रूटलोकस

7
मैं वास्तव में यह नहीं देखता कि प्रश्न "रचनात्मक नहीं" है, इसे समझाने की आवश्यकता होगी।
v.oddou

जवाबों:


42

कुछ डेवलपर्स करते हैं, कुछ डेवलपर्स (गेम और अन्य जगहों पर) नहीं करते हैं। यह इस बात पर निर्भर करता है कि उन डेवलपर्स की जरूरतें / आवश्यकताएं क्या हैं और मौजूदा तकनीक का उन्हें क्या फायदा उठाना है।

C ++ की मानक लाइब्रेरी को अक्सर एक ही उपचार दिया जाता है, और लोग अक्सर उसी चीज को आश्चर्यचकित करते हैं , जिसके बारे में आप सोच रहे हैं। अधिकांश कारण समान हैं, उदाहरण के लिए:

  • एक डेवलपर के पास पहले से ही कार्यक्षमता का एक इन-हाउस पुस्तकालय हो सकता है जो वही सेवाएं प्रदान करता है जो मानक पुस्तकालय या बूस्ट प्रदान करता है। इन-हाउस लाइब्रेरी अक्सर बहुत पहले लिखी जाती थीं, जब मानक पुस्तकालय के लिए कार्यान्वयन समर्थन कमजोर था और बूस्ट मूल रूप से अस्तित्वहीन था, इसलिए उन्हें अधिक-या-कम लिखना पड़ता था। इस परिदृश्य में, यह वास्तव में इन-हाउस कार्यक्षमता से दूर जाने के लायक नहीं है - यह एक प्रमुख पोर्टिंग प्रयास होगा जो बहुत सारे कोड को अस्थिर करेगा, और लगभग कोई लाभ नहीं प्रदान करेगा।

  • एक डेवलपर उन प्लेटफार्मों पर काम कर सकता है जहां बूस्ट द्वारा ली गई उन्नत सी ++ तकनीकों के लिए कंपाइलर समर्थन अच्छी तरह से समर्थित नहीं है, जैसे कि बूस्ट कोड बिल्कुल भी संकलन नहीं करता है या बहुत खराब प्रदर्शन करता है। यह मानक पुस्तकालय पर भी लागू होता है, हालांकि इन दिनों बहुत कम है।

  • बूस्ट और भाषा के मानक पुस्तकालय सामान्य उद्देश्य हैं, और जबकि यह ठीक है और अधिकांश अनुप्रयोगों के लिए अच्छा है, कभी-कभी एक डेवलपर के पास विशिष्ट आवश्यकताएं होती हैं जिन्हें अधिक विशिष्ट कंटेनरों द्वारा बेहतर तरीके से संबोधित किया जा सकता है।

मुझे लगता है कि उपरोक्त दो उचित कारण हैं, हालांकि निश्चित रूप से अन्य हैं। आपको हालांकि सावधान रहना होगा क्योंकि बूस्ट से बचने के कई कारण, मानक पुस्तकालय, या जो भी "यहाँ का आविष्कार नहीं किया गया है" सिंड्रोम को उबालते हैं, जो एक संकेत हो सकता है कि कारण व्यावहारिक वास्तविकताओं में बहुत अच्छी तरह से आधारित नहीं है।

यह भी याद रखें कि एक बड़े-ईश स्टूडियो की ज़रूरतें आमतौर पर एक व्यक्तिगत डेवलपर की ज़रूरतों से बहुत अलग होती हैं। उदाहरण के लिए, एक व्यक्तिगत डेवलपर के पास शायद कम विरासत कोड होता है जो बनाए रखने के लिए चारों ओर तैरता है और इसलिए शायद बूस्ट या मानक पुस्तकालय कार्यक्षमता के एक घर-विकसित संस्करण से पोर्टिंग टाइम सिंक के रूप में बड़ा नहीं होगा और उस डेवलपर को बनाए रखने से बचाएगा। उस कोड को भविष्य में बड़े पैमाने पर - इस प्रकार मेरी पहली बुलेट बिंदु को अमान्य करना।

अंत में, यह आपके वांछित लक्ष्य के विरुद्ध आपकी आवश्यकताओं और समय के निवेश का मूल्यांकन करने और यह निर्धारित करने के बारे में है कि कौन सा विकल्प आपकी आवश्यकताओं को पूरा करता है। डेवलपर्स जो बूस्ट या मानक पुस्तकालय का उपयोग नहीं कर रहे हैं, उन्होंने आमतौर पर ऐसा किया है और उस निष्कर्ष पर पहुंच गए हैं - शायद आप भी करेंगे, और शायद नहीं।


2
एक अन्य बिंदु - कुछ कंपनियों ने बूस्ट का उपयोग नहीं किया है क्योंकि यह अत्यधिक अंतर विकास वातावरण में संकलन गति पर नकारात्मक प्रभाव डालता है।
स्टीवन

27

कुछ वर्षों के बाद इस प्रश्न पर वापस आना संपादित करें कुछ वर्षों
से अधिक से अधिक पुस्तकालयों का उपयोग करना जारी रहा, मैंने सोचा कि मैं इस प्रश्न को अपडेट करूंगा कि जब उत्पाद का विवरण आपकी वांछित कार्यक्षमता से मेल खाता है तो आपको बूस्ट का उपयोग क्यों करना चाहिए। यह भी नेकदिल लोगों को मना लेंगे। ओपनएसएसएल डाउनलोड करें, इसके साथ एक क्लाइंट और सर्वर एप्लिकेशन बनाने का प्रयास करें। अब कोशिश करें और हर प्लेटफॉर्म पर वह काम करें। फिर, एक ही आवेदन करने के लिए बढ़ावा :: asio :: ssl डाउनलोड और उपयोग करें। यदि आप आश्वस्त नहीं हैं कि स्वच्छ, अच्छी तरह से अनुकूलित, सहकर्मी की समीक्षा, क्रॉस-प्लेटफ़ॉर्म कोड देखने के लिए बढ़ावा देने के लिए सही जगह है, तो यह सरल व्यायाम आपको परिवर्तित कर देगा।

टीएल; डॉ। संस्करण:

मेरी राय में, आप एक टन इंडी या छोटे से मध्यम आकार की विकास फर्मों को बढ़ावा देने का उपयोग करते हुए नहीं देखते हैं क्योंकि यह एक विशाल और शक्तिशाली जंगली जानवर है जो कि वश में करना आसान नहीं है और आप मूल रूप से अपने दम पर हैं कि कैसे सीखने की कोशिश कर रहे हैं इसके प्रयेाग के लिए। प्रलेखन में कुछ तरीकों की कमी है (लंबे संस्करण देखें) और परियोजना के आसपास "समुदाय" या तो गायब, बिखरे या निष्क्रिय (अन्य परियोजनाओं की तुलना में) प्रतीत होता है।

बहुत लंबा घुमावदार संस्करण:

मुझे लगता है कि पहले से ही एक स्वीकृत उत्तर है लेकिन जैसा कि कोई व्यक्ति जो वास्तव में मेरे द्वारा किए जाने वाले लगभग हर प्रोजेक्ट में बढ़ावा देता है, मैंने सोचा कि मैं एक उत्तर पोस्ट करूंगा।

मुझे याद है कि जब मैं पहली बार बढ़ावा देने के लिए इधर-उधर घूम रहा था और ईमानदारी से मुझे कोई भयावह विचार नहीं था कि क्या हो रहा था। बूस्ट बहुत अच्छी तरह से प्रलेखित नहीं है। लोग इस पर मुझसे असहमत हो सकते हैं कि मुझे यकीन है क्योंकि उदाहरण कोड और टिप्पणियों और इस तरह के स्निपेट्स के टन हैं, लेकिन यह सब बहुत ठंडा और अस्पष्ट है और साथ ही साथ नेविगेट करना मुश्किल है।

इसके अलावा किसी भी ऐसी जगह को ढूंढना मुश्किल है जहां आपको ऐसा लगे कि आपने प्रोजेक्ट के आसपास "समुदाय" पाया है। वास्तव में समुदाय गैर-मौजूद है, या खानाबदोश लगता है। दुर्भाग्य से यहां तक ​​कि उनकी मेलिंग सूची को कई जोंक साइटों द्वारा ट्रोल किया गया है कि आप इस खरगोश छेद को नीचे जा सकते हैं, जहां आप शुरू कर रहे थे, वहां वापस लूपिंग कर रहे थे।

इन दो कारकों को बढ़ावा पुस्तकालयों के बजाय एक कठिन काम सीखने के लिए बनाते हैं। यहां तक ​​कि अगर बूस्ट का उपयोग करने की तकनीकी अत्यधिक जटिल नहीं है, तो यह पुस्तकालयों का एक विशाल सेट है और इसे नीचे घूर रहा है जब आप सभी से लैस हैं कुछ कोड स्निपेट और इंटरनेट के सबसे गहरे कोनों से मेलिंग सूची के टुकड़े बिखरे हुए हैं। ... खैर, आप विचार समझ गए।

मैं संस्करण 1.45 के आसपास बढ़ावा देने के साथ छेड़छाड़ करने लगा और यह अब केवल 1.52 / 1.53 संस्करण में है कि मैं इसे उत्पादन में उपयोग करने के लिए काफी सहज महसूस करता हूं। उपयोग करने और याद रखने के लिए बहुत सी चीजें हैं, यहां तक ​​कि सरल चीजें भी हैं जैसे आपने कॉन्फ़िगरेशन को कैसे बढ़ाया और याद किया है, क्योंकि पुस्तकालयों का निर्माण कैसे किया जाता है और फ़ंक्शन अनुकूलन योग्य चीजों के कारण संकलन समय पर आपकी प्राथमिकताओं के आधार पर बेतहाशा भिन्न हो सकते हैं। कर रहे हैं।

हालांकि , कोई गलती न करें , एक बार जब आप को बढ़ावा दे सकते हैं, तो आप तेजी से ठोस, क्रॉस-प्लेटफॉर्म कार्यक्रमों के निर्माण के लिए एक शक्तिशाली हथियार प्राप्त कर चुके हैं। बस boost::asioउदाहरण के लिए ले लो । आप बस दो सौ लाइनों में एक बेहद शक्तिशाली, स्केलेबल और रॉक सॉलिड क्रॉस प्लेटफॉर्म अतुल्यकालिक वेब सर्वर लिख सकते हैं। मैंने कई ग्राहकों, सर्वरों, परदे के पीछे आदि को कोड की कुछ सौ पंक्तियों के साथ वर्षों में लिखा है जो अभी तक मुझे विफल करने के लिए हैं, और उन्हें प्लेटफ़ॉर्म से प्लेटफ़ॉर्म पर मिनटों में पोर्ट कर सकते हैं।

जैसा कि दूसरों ने बताया है, बड़ी कंपनियां आमतौर पर विरासत सामान के साथ फंस जाती हैं या अपना खुद का रोल करना पसंद करती हैं, जिसे मैं पूरी तरह से समझता हूं। वहाँ भी मैं वास्तव में मूर्खतापूर्ण बात के बारे में सुना है और सामना किया है, जहां देव नेतृत्व और या परियोजना प्रबंधकों ने बढ़ावा का उपयोग करते हुए मना किया है क्योंकि यह "बहुत बड़ा है"। मेरा अनुमान है कि उनका मानना ​​है कि बढ़ावा 1 एकल पुस्तकालय है या उन्होंने बीसीपी के बारे में कभी नहीं सुना है ।

WHY के लिए मैं बूस्ट का उपयोग करना चुनता हूं

मैं कहता हूं कि मैं इसका उपयोग करता हूं क्योंकि जैसा कि आप अपने प्रश्न में लगाते हैं, यह "सी ++ लाइब्रेरी" है। बूस्ट को सी ++ दुनिया में उन चीजों के स्विस सेना चाकू के रूप में देखा जाता है जो अंततः आपको उपयोग करने की आवश्यकता होती है। इसलिए विचार यह है कि यदि कोई आवश्यकता है, तो एक उच्च प्रदर्शन करने वाला होना चाहिए, और इसे बढ़ावा देने का पोर्टेबल संस्करण होना चाहिए। बड़ी कंपनियां बढ़ावा देने में योगदान देती हैं , प्रभावशाली रिज्यूमे वाले बहुत से शिक्षित लोग इसमें योगदान देते हैं और इसे बनाए रखते हैं , और जब सी ++ का एक नया मानक विकसित किया जा रहा है, तो लोग आमतौर पर यह देखने के लिए बढ़ावा देते हैं कि इसके कौन से हिस्से आईएसओ मानकीकृत सी ++ बनें।

इसलिए अगर मुझे कुछ ऐसी कार्यक्षमता जोड़ने की आवश्यकता है जो संभवत: एक मौजूदा पुस्तकालय के लिए है, तो पहली जगह जो मैं देखूंगा, वह सिर्फ इसलिए बढ़ावा दे रहा है क्योंकि मैं सट्टेबाजी में बहुत सुरक्षित हूं कि यह बहुत अच्छी तरह से अनुकूलित, पोर्टेबल है, इसके लिए समर्थन और रखरखाव किया जाएगा। एक बहुत लंबा समय और कीड़े मिल जाएंगे और इससे निपटा जाएगा। खुले स्रोत की दुनिया में उन गुणों का आना बहुत मुश्किल हो सकता है।


प्रलेखन के लिए बहुत सही है। उदाहरण के लिए, Boost.asio doc की इच्छा है कि आश्चर्यजनक रूप से कुछ पंक्तियों में एक http सर्वर कैसे लिखें, जो कि यदि आपका गेम http (या उस मामले के लिए कोई अन्य वैनिला टीसीपी प्रोटोकॉल) का उपयोग करता है तो बहुत अच्छा है, लेकिन यदि आप उपयोग करना चाहते हैं तो यह बहुत मुश्किल हो जाता है। एक कस्टम प्रोटोकॉल या मालिकाना नेटवर्क लाइब्रेरी। बूस्ट.आसियो का उपयोग करके वेबसोकेट सर्वर बनाने के तरीके को समझने में मुझे 20 मिनट का समय लगा, लेकिन एक कस्टम बूस्ट.आसियो io_service के माध्यम से एनेट ( enet.bespin.org ) का उपयोग करने के तरीके को समझने के लिए सप्ताह ।
क्लोसेटगीक

21

हमने अपने पुराने कार्यस्थल पर वापस बूस्ट का थोड़ा उपयोग किया। ज्यादातर इसे से बचने और इसके उपयोग को सीमित करने के मुख्य कारण थे:

  • संकलन का समय - इसका कुछ संकलन करने के लिए बहुत धीमा है, और आप अपने किसी भी हेडर में #includes को बढ़ावा देने के लिए अनिच्छुक हैं।
  • जटिलता - यह ज्यादातर गेम डेवलपर्स द्वारा अच्छी तरह से नहीं जाना जाता है और इसलिए अपठनीय कोड के लिए बनाता है
  • प्रदर्शन - कुछ अवधारणाएं डिफ़ॉल्ट रूप से धीरे-धीरे प्रदर्शन करती हैं, जैसे। shared_ptr

1
को बढ़ावा देने :: shared_ptr? ऐसा कैसे?
टिली

6
अगर मुझे सही याद है, तो यह कहीं पर ढेर पर संदर्भ गणना को आवंटित करता है। यह उपयोग के दौरान कैश सुसंगतता के लिए बहुत बुरा है और इसका मतलब है कि शुरू और अंत में आवंटन और डीलक्लोलेशन समय को दोगुना करना।
काइलोटन

10
(मेक_शेयर के उस उपयोग को जोड़ने से समस्या को कम किया जा सकता है।)
काइलोटन

मुझे लगता है कि यह उत्तर बिल्कुल स्पष्ट है कि ऐसे और भी कारण हैं जिनसे लोग केवल एक या दो बुरे वर्गों को चकमा देने से बचते हैं।
काइलोटन

16

"अधिक मानक" एसटीएल के लिए एक ही बात (है?) की जा रही है। यह लेख EASTL के बारे में बात करता है, इलेक्ट्रॉनिक आर्ट्स द्वारा एसटीएल (इन) के इन-हाउस पुनर्लेखन के साथ खेल विकास की जरूरतों को पूरा करने के लिए जो "अधिक सामान्य" अनुप्रयोग विकास के बजाय अलग-अलग हैं।

इसलिए, हो सकता है, कोई व्यक्ति कहीं न कहीं फिर से लिख रहा हो (के कुछ हिस्सों को) खेल के विकास में उनकी जरूरतों को पूरा करने के लिए बढ़ावा देता है!


लेख के लिए +1। मुझे लगता है कि यह सवाल का जवाब खूबसूरती से देता है।
एगारिया

9
मेरा अनुभव यह है कि जितना अधिक पोर्टेबल आपका कोडबेस बन जाता है, उतना ही आप एसटीएल की तरह "मानक" घटकों का पुनर्लेखन करते हैं।
जरी कोमप्पा

6

कौन कहता है कि वे बढ़ावा का उपयोग नहीं करते हैं? मैंने एक या दो C ++ इंजनों का उपयोग किया है जिन्हें बढ़ावा दिया है। मैंने कभी उनके साथ सीधे काम नहीं किया है; लेकिन, यह ज्यादातर 'असत्य में मेरा अनुभव निहित है।

बढ़ावा देने का उपयोग नहीं करने के लिए मैंने जिन कारणों का सामना किया है, और ये व्यक्तिपरक हैं:

  • हम अपनी स्वयं की डेटा संरचनाओं को उन प्लेटफ़ॉर्म पर रोल करना पसंद करते हैं, जिन्हें हम परिनियोजित कर रहे हैं
  • हम अपनी परियोजनाओं में उपयोग किए जाने वाले गैर-आंतरिक रूप से विकसित कोड की मात्रा को सीमित करना पसंद करते हैं, खासकर जब बाहरी कोड अन्य बाहरी विकसित पुस्तकालयों पर निर्भर होता है।

यह मूल रूप से उबलता है: एक सामान्य समाधान हमेशा "सही फिट" नहीं होता है।

मुझे यकीन है कि कोई व्यक्ति जो वास्तव में पुस्तकालय के साथ काम करता है, बेहतर टिप्पणी कर सकता है।


सच है, इसके लिए मेरे प्रश्न को संपादित करें।
जेम्स

5

मैं StackOverflow में बाहर घूमता हूँ और बढ़ावा का उपयोग नहीं करता। मैं अपना कारण जोड़ूंगा, क्योंकि यह अभी तक उल्लेखित नहीं है।

बूस्ट के पास कई बेहतरीन विचार हैं। मुझे यह देखना पसंद है कि उन्होंने क्या किया है और नई चीजों और विचारों को आजमाते हैं। वे महान हैं, क्योंकि यह कई सी ++ सुधारों के लिए प्रजनन भूमि है।

लेकिन बढ़ावा कई कारणों से एक बहुत ही दुष्ट जानवर है। एक कारण यह है कि उन्हें किसी भी quirks के साथ लगभग किसी भी संकलक पर संगत होने की आवश्यकता है (चाहते हैं)। परिणामस्वरूप उन्हें कई चालों को नियोजित करने की आवश्यकता होती है, जैसे कि इसे हटाने के लिए एमपीएल। उदाहरण के लिए (बहुत समय पहले) मैं उनके शेयर्ड_प्ट्र का उपयोग करना चाहता था, इसे चलाने का मतलब था कि मुझे 90% बूस्ट के स्रोतों और पुस्तकालयों की आवश्यकता थी। मैंने अपना लिखना समाप्त कर दिया; कोड की 50 पठनीय लाइनें। (मेरी आवश्यकताएं जहां सख्त होती हैं, जैसे कोई कमजोर_ धागा या सुरक्षा नहीं।)

अक्सर आपको बढ़ावा देने के लिए वास्तव में छोटे उपसमूह की आवश्यकता होती है, लेकिन बढ़ावा देने की संपूर्णता को एकीकृत करना सिर्फ परेशानी के लायक नहीं है।

संपादित करें :

बस स्पष्ट करना है, क्योंकि यह प्रतीत नहीं होता है कि स्पष्ट रूप से आया है (यानी नीचे)। मैं थर्ड पार्टी लाइब्रेरी का उपयोग करता हूं । लेकिन ज्यादातर मामलों में, सभी चीजें बराबर होती हैं, एक तीसरे पक्ष के पुस्तकालय को बढ़ावा देने या बढ़ावा देने के लिए, अन्य तीसरे पक्ष का पुस्तकालय तेज और क्लीनर है। शेष "2h" उंगली व्यायाम में किया जाता है। मैं इसे बनाने या प्रश्न खरीदने में बहुत कठिन नज़र रखता हूं।


1
बीसीपी, y'know जैसे उपकरण हैं।
बार्टेक बैंचेविक्ज़

2
क्या आप इसका मतलब निकाल रहे हैं कि आपको अपना कोड बनाए रखने की ज़रूरत नहीं है? इसके अलावा, मैं चाहता हूं कि मैं 2 घंटे में उपयोग कर रहे बूस्ट के सभी हिस्सों को लिखने में सक्षम होने के लिए अच्छा था (जिसमें उन्हें उन सभी बिल्ड लक्ष्यों पर परीक्षण करना भी शामिल है जो मैं उपयोग करने जा रहा हूं, और परीक्षण लिख रहा हूं)। आपको वास्तव में तेज़ कोडर होना चाहिए। ओह, और यहां तक ​​कि "अधिकांश उपयोगी बिट्स" यहां "मैं सी ++ नहीं कर सकता" के बराबर है, क्योंकि मानक में अभी भी बहुत कमी है
बार्टेक बानचेविच 10

2
शुरुआत द्वारा प्रदान की जाने वाली कुछ सुविधाओं के लिए, मैंने छोटे से परिभाषित पैकेजों में कहीं और पाया, उदाहरण के लिए sigc ++। कई मामलों में अधिक सुरुचिपूर्ण और / या अधिक कुशल। मैं सबसे अधिक सुविधाओं के लिए क्या आया था, जैसे कि थ्रेड्स, स्मार्ट पॉइंटर्स और नियमित अभिव्यक्तियाँ, चीजें जो इसे मानक में बनाती हैं। पिछले कुछ वर्षों में मैंने थर्ड पार्टी लाइब्रेरी और अपने खुद के कुछ कोड का संग्रह हासिल किया है। "मैं C ++" 15 से अधिक वर्षों के लिए कर सकता हूं, बहुत-बहुत धन्यवाद।
रीओकी

3
@ सीनियरेल आपको कृपालु नहीं होना चाहिए। आप कहते हैं कि आप 15 साल से C ++ कर रहे हैं और फिर बार्टेक के लिए एक व्यंग्यात्मक टिप्पणी में ऐसा लगता है कि आपको समझ में नहीं आ रहा है कि बार्टेक का क्या मतलब है जब वह "पैकेज" के साथ संयोजन में "बनाए रखता है"। बनाए रखने का मतलब उन्हें ठीक करना नहीं है। बस एक नई रिलीज के लिए अद्यतन या कई लक्ष्यों के लिए संस्करणों का भंडारण आमतौर पर इसका मतलब है। सिर्फ आपकी जानकारी के लिए।

3
Sigh Boost बॉक्स से बाहर भी काम करता है, फिर भी आपने इसे बनाए रखने का उल्लेख किया है। मैं आपके तर्क को यहां देखने में विफल हूं।
बार्टेक बैंचेविक्ज़

4

हमारे मामले में (गेम नहीं), हमारे पास बूस्ट (न ही एसटीडी) का उपयोग न करने का एक बड़ा कारण है: हमारे पास बहुत सारे कोड हैं जो एक दशक पहले वापस आते हैं। वरिष्ठों के अनुसार, एसटीडी और बढ़ावा या तो अधूरा था, बग से भरा हुआ था या उच्च प्रदर्शन वाली चीजों के लिए बहुत धीमी गति से हम की आवश्यकता होती है। तो कुछ आधार वर्गों को लागू किया गया था, समान अवधारणाओं (जैसे पुनरावृत्तियों) का उपयोग करके और अक्सर हमारे एल्गोरिदम के लिए अनुकूलित। आजकल, सभी तीन पुस्तकालय (हमारे, एसटीडी और बढ़ावा) बहुत समान हैं।

लेकिन क्या हम अपने सभी कोड को पोर्ट करना चाहते हैं? ज़रुरी नहीं। मुझे लगता है कि कई अन्य कंपनियां भी उसी दुविधा का सामना कर रही हैं। या तो बहुत सारे परीक्षण किए गए और काम करने वाले कोड को फिर से लिखें या एसटीडी / बूस्ट का उपयोग न करें।


5
यह सच है, और कुछ ऐसा है जिसके बारे में मैंने नहीं सोचा था, लेकिन मैंने देखा कि C ++ में खेल के विकास पर शुरू होने वाले बहुत से लोग बूस्ट / एसटीडी का उपयोग करने की परवाह नहीं करते हैं। कभी-कभी मुझे लगता है कि यह इसलिए है क्योंकि सीखने को बढ़ावा देना पूरी तरह से नई भाषा सीखने जैसा है।
जेम्स

1
@ जेम्स यह सबसे बड़ी वजहों में से एक है। मैंने एक उत्तर पोस्ट किया, भले ही आप पहले से ही अपना दृष्टिकोण देने के लिए किसी को स्वीकार कर चुके हैं, जो किसी ऐसे व्यक्ति के रूप में है जो बढ़ावा देने के आसपास मेरे तरीके से सीखता है, लेकिन साथ ही साथ उससे दूर भागने का लालच नहीं किया जाता है।

1

मैं व्यक्तिगत रूप से गेम बनाते समय बूस्ट या किसी अन्य सामान्य प्रयोजन कोड का उपयोग नहीं करता, क्योंकि खेल आम तौर पर सामान्य उद्देश्य नहीं होते हैं। एक गेम को लागू करने के लिए जिस तरह के कोड की आवश्यकता हो सकती है, वह आमतौर पर गेम डेवलपमेंट के लिए विशिष्ट होती है, हमेशा नहीं बल्कि उस समय के 98% (रैंडम फिगर) की तरह। आप बूस्ट या कुछ अन्य लीब से कोड के उस अंतिम कुछ बिट्स पर व्यवहार कर सकते हैं, लेकिन शायद यह बेहतर है कि आप उन छोटे हिस्से को लिखें जो आपको यहां और वहां चाहिए।

एक साइड नोट पर, मुझे लगता है कि सी ++ में अपना कोड लिखने के बजाय यह मजेदार है, यही कारण है कि मैंने कभी भी बढ़ावा या इसके जैसा कुछ भी उपयोग नहीं किया है।


3
यह मज़ेदार है, लेकिन बढ़ावा ऐसे लोगों के लिए है जो पहिया को सुदृढ़ करने के बजाय श * टी करना चाहते हैं।
बार्टेक बैंचेविक्ज़

3
यह मेरी राय है, लेकिन यह कहना कि "खेल विशेष हैं" यह एक गिरावट है। हाँ, वास्तविक समय उद्योग स्वचालन भी विशेष है। मैं दोनों करता हूं और अटेस्ट कर सकता हूं, कि बिट्स जहां बढ़ावा देगा, बहुत स्पष्ट रूप से समान हैं। यह कहना कि वे भिन्न हैं अज्ञानता है, क्योंकि भित्तिचित्रों पर वे बहुत भिन्न हैं लेकिन मूल भाषा का उपयोग समान है। एक प्रकार का कार्य मूल रूप से वही होता है जो आपके द्वारा छांटे गए कोई फर्क नहीं पड़ता। (फिर दोबारा, बस इतना ही कर सकते हैं, इसका मतलब यह नहीं है कि आप चाहते हैं, मेरा जवाब देखें।)
rioki

2
आप बढ़ावा देने का उपयोग करके अपने गेम में पूरी नेटवर्किंग / मल्टीप्लेयर परत जोड़ सकते हैं :: asio और इसके लिए अपने स्वयं के संचार प्रोटोकॉल का आविष्कार करें। बूस्ट का उपयोग करने के लिए यह 100% पूरी तरह से वैध कारण है आप कभी भी लिख सकते हैं कि किसी भी तरह के नेटवर्क से संबंधित फ़ंक्शन की आवश्यकता है। "अपनी खुद की रोलिंग" बहुत अच्छी हो सकती है जब आप नए हों और आपको सीखने की आवश्यकता हो। कुछ गलत नहीं है उसके साथ। लेकिन दिन के अंत में मैं अपना क्रॉस प्लेटफॉर्म अतुल्यकालिक संचार परत लिखने की कोशिश में समय बर्बाद नहीं करने जा रहा हूं जब यह पहले से ही किया गया है और उस पर अच्छी तरह से है।

2
@HaywireSpark लोगों का अपमान शुरू करने की कोई जरूरत नहीं है। मैंने आपकी पोस्ट पढ़ी, और अभी भी आपसे असहमत हूं। यहां तक ​​कि अगर आप "आम तौर पर विशिष्ट" के साथ जाते हैं, तो यह पूरी तरह अप्रासंगिक है। लगभग हर चीज को बढ़ावा देने के लिए संभव के रूप में पोर्टेबल और पारस्परिक रूप से बनाया गया है। बढ़ावा देना :: asio एक बहुत ही सामान्य कार्यान्वयन है और नेटवर्क संचार के किसी भी विशिष्ट तरीके की ओर गियर नहीं है। मैं किसी भी परिदृश्य की कल्पना नहीं कर सकता, जहां मुझे "जी, बूस्ट :: एशियो कहना होगा, सिर्फ मेरे नेटवर्किंग लेयर मॉडल को फिट नहीं करता है जो कि मैं पहिया को बेहतर बनाता हूं"। बस केह रहा हू।

2
@HaywireSpark आहें। आपका दिन शुभ हो आपको आलोचना के लिए अधिक खुले होने की कोशिश करनी चाहिए। आलोचना को स्वीकार करने में सक्षम होने के नाते दुखी होने का एक हिस्सा है, और यदि आप नहीं हो रहे हैं तो आप कभी भी एक चीज नहीं सीखेंगे। मैं तुम पर नहीं उठा रहा हूँ। आपकी टिप्पणी पर पोस्ट किया गया हर व्यक्ति आपसे असहमत है। यह आमतौर पर एक अच्छा संकेत है कि आपने कुछ असहनीय कहा है।

0

घर के पुस्तकालयों में विरासत एक कारक नहीं है ... मुख्य कारण किसी को भी यू सामान्य प्रयोजन पुस्तकालय का उपयोग नहीं करना चाहिए क्योंकि वे गति और स्मृति को अनुकूलित नहीं कर रहे हैं, मुझे यह उल्लेख करना होगा कि क्रायेंगिन एसटीएल का उपयोग करता है लेकिन वे संकलन करते हैं यह STLPort नाम के एक ओपन सोर्स वर्जन से जुड़ा है, इसलिए STL का उपयोग करने से न डरें, बस अपने कस्टम एलोकेटर को लागू करें और आप ठीक हो जाएंगे। बूस्ट थो का उपयोग न करें।


5
-1: आपके विश्वास के लिए कि "बूस्ट" "अनुकूलित गति और स्मृति नहीं है", जब शाब्दिक रूप से दर्जनों बूस्ट लाइब्रेरी होती हैं, सभी में गति और स्मृति दक्षता की बदलती डिग्री होती है।
निकोल बोलस

2
... यही कारण है कि वास्तव में है कारण खेल डेवलपर्स के एक नंबर को बढ़ावा देने से बचने और यहां तक कि अपने स्वयं के एसटीएल रोल तथ्य यह है कि भारी टेम्पलेट उपयोग ड्राइव छत के माध्यम से कई बार संकलन के साथ। विशेष रूप से ध्यान रखें डिबग MSVC पर बनाता है, जहाँ आपको एब्सट्रैक्शन और रैपर्स की पूरी न्यूनतम मात्रा की आवश्यकता होती है और जेनेरिकवाद से आप दूर हो सकते हैं, ये सभी बूस्ट के लिए एंटीथेटिकल हैं। समस्या एल्गोरिदम नहीं है, लेकिन बस यह कि बूस्ट नंगे दशम धातु की गति के लिए कभी नहीं था। खेल डेवलपर्स से किसी को भी अलग नहीं करना चाहिए, वैसे भी व्यापार की आवश्यकता होगी।
सीन मिडिलिचच

2
@seanmiddleditch: मेरा कहना यह है कि बूस्ट में कई लाइब्रेरी हैं । उनमें से कुछ तेजी से और अधिक स्मृति कुशल हैं कुछ भी आप एक ही काम करने के लिए कोड कर सकते हैं, और उनमें से कुछ भी नहीं हैं। इसके लिए पुस्तकालयों के पूरे सेट को बदनाम करना केवल अज्ञानी है।
निकोल बोलस

2
ऐसे कई गेम डेवलपर नहीं हैं जो एक बूस्टर लिख सकते हैं जो Boost.Spirit से तेज है। जहां संपूर्ण भाषाओं को पार्स करने के लिए कई बेहतर (उपयोग करने में आसान) विकल्प हैं, आत्मा अच्छी तरह से संरचित स्ट्रिंग्स को पार्स करने में बहुत तेज है, यहां तक ​​कि सिर्फ स्ट्रिंग को डेटा प्रकारों में परिवर्तित करना। Boost.Xpressive लाइब्रेरी भी regex के लिए बहुत तेज़ है। इस बात को ध्यान में रखें कि बूस्ट पर काम करने वाले कई लोग ऐसे लोग भी हैं जो C ++ मानक समिति पर काम करते हैं, और वे जानते हैं कि प्लेटफार्मों भर में C ++ से इष्टतम प्रदर्शन कैसे प्राप्त किया जाए।
जेराल्ड

5
वे अक्सर ऐसे तरीकों से टेम्पलेट मेटाप्रोग्रामिंग का उपयोग करते हैं जो काम के बड़े हिस्से को रन-टाइम के बजाय संकलन-समय पर करने की अनुमति देते हैं, जो किसी भी निम्न-स्तरीय रनटाइम ऑप्टिमाइज़ेशन में से नर्क को हरा देगा जो गेम डेवलपर्स को बहुत गर्व होता है । मैंने बूस्ट समकक्षों का उपयोग करने के लिए कुछ सामान्य उच्च प्रदर्शन सी पुस्तकालयों से कुछ कार्यों को परिवर्तित करते हुए 50x से अधिक के कुछ प्रदर्शन में वृद्धि देखी है।
गेराल्ड
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.