बूस्ट ग्राफ लाइब्रेरी के साथ मेरा जीवन

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

बीजीएल और इसके साथ क्या खाया जाता है

BGL टेम्पलेट लाइब्रेरी संभवतः किसी भी डेवलपर के लिए जानी जाती है जिसने ग्राफ़ कार्यों का सामना किया है। 2000 में बूस्ट 1.18.1 में दिखाई देने पर, उन्होंने तुरंत ही अलेक्जेंडर स्टेपानोव के रूप में शैली के ऐसे क्लासिक्स से समीक्षा प्राप्त की। पुस्तकालय मैनुअल, जेरेमी सिक, लाई-क्वान ली और एंड्रयू लम्सडेन द्वारा संकलित, 2006 में पीटर (मूल - जेरेमी जी। साइक, ले-क्वान ली और एंड्रयू लम्सडाइन, "द बूस्ट लाइब्रेरी") द्वारा रूसी में प्रकाशित किया गया था। , एडिसन-वेस्ले)। लाइब्रेरी को 2013 के अंत तक (बूस्ट 1.55.0) तक गहन रूप से अद्यतन और विकसित किया गया था। विशेष रूप से, 2005 में, इसके वितरित संस्करण (पीबीजीएल) की घोषणा दिखाई दी, जो 2009 में संस्करण 1.40 से बूस्ट में शामिल किया गया था और आज तक उच्च प्रदर्शन वाले क्लस्टर पर ग्राफ कंप्यूटिंग के लिए एक प्रकार का वास्तविक मानक बना हुआ है, किसी भी मामले में, अकादमिक दुनिया में। जहां तक ​​कमिट्स के इतिहास का अंदाजा लगाया जा सकता है, 2005 तक, लाइब्रेरी के मुख्य डेवलपर जेरेमी सिक थे, 2005 के बाद - डगलस ग्रेगर, और सामान्य तौर पर कई बार लाइब्रेरी में काफी संख्या में विविध लोगों ने काम किया। इसके लिए समर्पित प्रकाशन बार-बार habr.com पर दिखाई देते हैं: सबसे पहले, वादिम एंड्रोसोव के लेखों की एक श्रृंखला को नोट किया जाना चाहिए: [ 1 , 2 , 3 ]। इस प्रकार, सिद्धांत रूप में, अच्छा और विविध साहित्य पुस्तकालय के लिए समर्पित है, लेकिन इसके स्वयं के प्रलेखन, भी, आम तौर पर बोल, काफी व्यापक, इस तथ्य के कारण कुछ हद तक ग्रस्त है:

1. इसकी सामग्री और मूल वर्गों की तालिका, जो प्रमुख संस्थाओं की एक विस्तृत सूची प्रदान करने का दावा करती हैं, 2001 के बाद से नहीं बदली हैं। उदाहरण के लिए, इन पंक्तियों के लेखक, जो भोलेपन से मानते थे कि:

   बीजीएल वर्तमान में दो ग्राफ कक्षाएं और एक एज सूची एडाप्टर प्रदान करता है:
   
   adjacency_list
   adjacency_matrix
   edge_list

   , कुछ समय बाद मैं 2005 में कार्यान्वित कंप्रेस्ड_सपारसे_रो_ग्राफ (स्पार्स मैट्रिक्स) प्रतिनिधित्व पाकर आश्चर्यचकित था। इसी तरह की कहानी ब्रॉन-केर्बोश एल्गोरिथम के साथ हुई। सामग्री की तालिका पर विश्वास न करें, हेडर फ़ाइलों में प्रत्यक्ष खोज का उपयोग करें;
   
2. लाइब्रेरी की आंतरिक श्रेणियों (कंटेनर_केटररी, समानांतर_श्रेणी_चित्र, पुनरावृत्ति_ अस्थिरता, आदि) की कोई एकल टिप्पणी सूची नहीं है जो आपके स्वयं के विचारों को लागू करने के लिए आवश्यक हो। यह समझने में समस्या कि क्या हो रहा है, स्पष्ट रूप से, लाइब्रेरी के सभी उपयोगकर्ता जो गहरी खुदाई करना चाहते हैं, जो "एक प्रकार का काम कोड" की उपस्थिति की ओर जाता है, जो इसे पूर्ण स्थिति में लाने में बहुत समय और प्रयास लेता है: उदाहरण के लिए, एक विशिष्ट चर्चा ।

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



इस अवसर पर यह ध्यान दिया जा सकता है कि इस तरह के लचीले तंत्र का पूर्ण परीक्षण एक अलग समस्या है, क्योंकि यह संभावित प्रतिस्थापनों की संख्या के दहनशील विस्फोट के साथ है।

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

इस प्रकार, 2019 से देखने पर ग्राफ अनुप्रयोगों के लिए एक संदर्भ पुस्तकालय चुनने के मुद्दे उतने स्पष्ट नहीं दिखते जितने हम चाहते हैं, और पिछले 5 वर्षों में, अनिश्चितता कम होने के बजाय बढ़ी है।

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

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

"मौलिक रूप से" शब्द का उपयोग एक कारण से किया जाता है। पहले से उल्लिखित लंबे समय से पीड़ित संकुचित_sparse_row_graph वर्ग के उदाहरण का उपयोग करके एक विशिष्ट स्थिति को ध्यान में रखते हुए, हम ध्यान दे सकते हैं, उदाहरण के लिए, उच्च मानकों से निम्नलिखित विचलन:

1. आसन्न सूची के लिए ऑपरेटर [] और विरल मैट्रिक्स किनारों के आंतरिक और बाह्य गुणों को अलग-अलग तरीके से (आंतरिक और बंडल किए गए गुण) संभालते हैं: पहला रिटर्न केवल बाहरी गुण (आंतरिक केवल संपत्ति_मैप के साथ सुलभ है), दूसरा रिटर्न एक फ्रैक्चर संरचना गुणों की एक सामान्य सूची से युक्त संपत्ति देता है।
2. बढ़ावा पाने के लिए बढ़त सूचकांक प्राप्त करने के लिए फ़ंक्शन प्राप्त करें :: property_map <compress_sparse_row_graph, बढ़ावा :: edge_index_t> :: प्रकार बूस्ट में गिर गया :: विवरण, और बढ़ावा नहीं, अन्य सभी मामलों में के रूप में।

अंत में, compress_sparse_row_graph टेम्पलेट में, अप्रत्यक्ष ग्राफ़ (बढ़ावा :: अप्रत्यक्ष) के लिए विशेषज्ञता अधूरी रह गई।

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

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

इसके अतिरिक्त, निम्नलिखित, इतना महत्वपूर्ण नहीं, असुविधाओं को नोट किया जा सकता है:

• ग्राफ़ अभ्यावेदन के आंतरिक विवरणकों के आयामों का ग्राफ़ को संग्रहीत करने के लिए आवश्यक मेमोरी खपत पर महत्वपूर्ण प्रभाव पड़ता है, और कभी-कभी एल्गोरिदम के प्रदर्शन को प्रभावित करता है।
  
  कुछ दृश्य (समान संपीडित_स्पर्श_रो_ग्राफ) आपको इन आयामों को नियंत्रित करने की अनुमति देते हैं। अन्य (निकटस्थ_सूची) में ऐसे पैरामीटर नहीं होते हैं और हमेशा 64-बिट पूर्णांक (आमतौर पर निरर्थक) का उपयोग करते हैं, जिसे कोड को संशोधित किए बिना प्रतिस्थापित नहीं किया जा सकता है;
  
• इस तथ्य के बावजूद कि पुस्तकालय के लेखकों ने बहुत, बहुत अधिक, कुछ स्पष्ट रूप से आवश्यक आदिमता के लिए पुस्तकालय में शामिल नहीं किया था। उदाहरण के लिए, रिवर्स इन्वेज जैसा कोई कार्य नहीं है जो एज इनवर्जन करता है।
  
  ऐसे कार्यों का कार्यान्वयन, निश्चित रूप से, ग्राफ प्रतिनिधित्व पर निर्भर करता है: इस मामले में, यह एक जोड़ी के तत्वों के एक तुच्छ विनिमय द्वारा कार्यान्वित किया जा सकता है, कंटेनर द्वारा अधिक या कम कुशल खोज, या बिल्कुल नहीं। अंत उपयोगकर्ता के लिए इस तरह के सभी विकल्पों को समझना मुश्किल है, खासकर जब से, पुस्तकालय की विचारधारा के अनुसार, विवरणकर्ताओं के आंतरिक सदस्यों को उसके लिए रुचि नहीं होनी चाहिए।
  
• इसी तरह, बेकार स्क्रिप्ट से कुछ दूर पुस्तकालय से बाहर गिर गया। उदाहरण के लिए, आप एक पूर्वनिर्धारित ग्राफ़ को एक निर्देशित ग्राफ़ में बदलने के लिए फ़िल्टर किए गए_ग्राफ का उपयोग करने वाले किनारे को परिभाषित कर सकते हैं, लेकिन लाइब्रेरी के ध्यान में इस परिवर्तन को लाने का कोई तरीका नहीं है। तदनुसार, निर्देशित ग्राफ़ के लिए नियमित एल्गोरिदम इस तरह के ऑब्जेक्ट के साथ संकलित नहीं करेगा, और अप्रत्यक्ष ग्राफ़ के लिए एल्गोरिदम इसके साथ सही ढंग से काम नहीं करेगा।
  
  कहीं पड़ोस में तकनीकी रूप से गैर-दिशात्मक रेखांकन के लिए समर्थन का विषय है जो किनारों पर एक सेवा दिशा मार्कर है। हालाँकि, इस दृष्टिकोण पर ध्यान देना उन कार्यों की विशेष प्रकृति के कारण हो सकता है जो लेखक हल करता है, और ऐसी वस्तुओं का समर्थन करने में व्यापक रुचि स्पष्ट नहीं है।
  
• जैसा कि ऊपर दिए गए एक उदाहरण के रूप में लिया गया है रिवर्स_लेज फ़ंक्शन के लिए, एक अविश्वसनीय विकल्प बिल्कुल नहीं है कि वांछित फ़ंक्शन लाइब्रेरी के आंत्र में कहीं मौजूद है, लेकिन किसी कारण के लिए एक अवज्ञाकारी नाम प्राप्त किया है। यह निम्नलिखित समस्या की ओर जाता है, जो पहली नज़र में गंभीर नहीं है, लेकिन जटिल टेम्पलेट पुस्तकालयों के साथ काम को धीमा कर देता है (न केवल बीजीएल, हालांकि यह इस मानदंड से नेताओं के बीच स्पष्ट रूप से है): स्पष्ट पैरामीटर टाइपिंग के साथ और बिना अंतर्निहित कार्यों के व्यापक सिस्टम के साथ काम करें। उपयोग के गैर-स्पष्ट शब्दार्थ (अक्सर अधिक सुविचारित से कम पारदर्शी) शारीरिक रूप से कठिन होते हैं, और मौजूदा विकास वातावरण डेवलपर में इसके लिए कोई सहायता प्रदान नहीं करते हैं:
  
  
  
  वास्तव में, स्वचालित सहायक:
  
  
  1. मुख्य रूप से OOP समर्थन के लिए डिज़ाइन किया गया है, जब फ़ंक्शन का एक सेट अपने प्रकार के अनुसार दाईं ओर ऑब्जेक्ट के लिए बाध्य है। वैश्विक कार्यों के साथ जो एक प्रकार के बाईं ओर हो सकते हैं (बहुत कम प्रकार का एक सेट), वे सभी प्रकार के ज्ञात होने पर भी बहुत खराब मदद करते हैं।
  2. वे हास्यास्पद रूप से सरल टेम्प्लेट के साथ भी काम करने में सक्षम नहीं हैं। लेखक द्वारा उपयोग किए जाने वाले दृश्य सहायक का संस्करण, डिफ़ॉल्ट मापदंडों के साथ एक टेम्पलेट वर्ग की परिभाषा के सामने, एक "परीक्षण प्रतिस्थापन" को निर्दिष्ट करने के लिए प्रदान करता है ताकि कक्षा के लिए एक संकेत उत्पन्न किया जा सके। यदि आप उससे मिलते हैं, तो कुछ भी नहीं होता है।
  3. इसके अलावा, वे मेटाप्रोग्राम क्वालीफायर को समझने में कम सक्षम हैं, यहां तक ​​कि सबसे सरल भी, जैसे कि enable_if।
  4. एक विशिष्ट परिदृश्य के बारे में: "हम एक टेम्प्लेट फ़ंक्शन के अंदर होते हैं, जिसे अन्य कार्यों की श्रृंखलाओं की अनिश्चित लंबाई से अनिश्चित काल तक कहा जाता है, जिसमें टेम्प्लेट भी शामिल हैं", बिना आँसू के बोलना असंभव है। इस मामले में, विम वास्तव में प्रोग्रामर का सबसे अच्छा दोस्त बना हुआ है।
  
  पिछली स्थिति में दिखाए गए कोड के टुकड़े की पहली पंक्ति का उपयोग करके उसी स्थिति का एक और पहलू चित्रित किया जा सकता है। पाठक को "सीआरटी वर्तमान समय" बनाम "वर्तमान समय को बढ़ावा देने" को पूरा करने के लिए आमंत्रित किया गया है और परिणामों की तुलना करें। हां, बढ़ावा :: date_time (अब आंशिक रूप से std में स्थानांतरित हो गया है) बहुत सारी जटिल चीजों को सही ढंग से करना संभव बनाता है, जबकि CRT आपको कई तुच्छ कार्यों को गलत तरीके से करने की अनुमति देता है, लेकिन आम रोजमर्रा की साधारण स्थितियों में CRT सभी दृष्टिकोणों से अधिक सुविधाजनक है, और बहुपत्नी हैं फार्म का निर्माण posix_time :: second_clock :: local_time (एक सौम्य उदाहरण) कार्यक्रम में घूमते हुए चित्रलिपि में बदल जाते हैं। इस तरह के चित्रलिपि के निजी पुस्तकालय तक पहुंच के विकासकर्ता को विकसित करें और विकास की गति शून्य हो जाएगी ।
  
  बूस्ट :: string_algo स्ट्रिंग्स के साथ कुछ भी करना संभव बनाता है, लेकिन, ईमानदारी से, प्रत्येक काफी तुच्छ ऑपरेशन पुस्तकालय के सामान्य तर्क को ताज़ा करने के लिए री-रीडिंग प्रलेखन के सत्र के साथ नहीं है, विधेयकों के नाम, साथ ही साथ मापदंडों की अनुकूलता का पता लगाने के लिए एक अलग अभ्यास है। इसी तरह की स्थिति को बढ़ावा देने में टोकन संचालन के साथ होता है :: regexp, उत्तरार्द्ध के निर्दोष आंतरिक तर्क के साथ।
  
  यदि ऐसी स्थिति सबसे अधिक उपयोग किए जाने वाले पुस्तकालयों के साथ होती है, तो यह आश्चर्य की बात नहीं है कि बीजीएल, एक अधिक विशिष्ट पुस्तकालय के रूप में, जिसमें, उदाहरण के लिए, make_property_map_function और make_function_property_map हैं जो एक-दूसरे से संबंधित नहीं हैं, साथ ही साथ एक पुण्य प्राप्त कार्य किसी भी व्यक्ति को पुनः लोड किया जाता है। किसी भी प्रकार के तर्कों की संख्या समान समस्याओं को जन्म देती है, लेकिन हाइपरट्रॉफ़िड रूप में। हां, किसी भी कार्य को प्राप्त कॉल श्रृंखला द्वारा हल किया जा सकता है, लेकिन, अफसोस, प्रत्येक श्रृंखला को इस समस्या का हल नहीं मिलता है।
  
  इस तरह के कोड को पढ़ना आसान और सुखद हो सकता है, यहां तक ​​कि यह एक प्राकृतिक भाषा में औपचारिक रूप से लिखे गए एल्गोरिथ्म के एक समानार्थी शब्द की तरह लग सकता है, लेकिन इसे लिखते समय, समानार्थी शब्दों के साथ शब्दों को प्रतिस्थापित करने की असंभवता, कठोरता की अभिव्यक्तियां, एक वास्तविक एक के लिए अप्राप्य है।
  
• सामान्य क्रम में, कोई भी भोज को दोहराने में विफल नहीं हो सकता है, लेकिन कम सच नहीं हो सकता है, यह अवलोकन कि सी ++ में मेटाप्रोग्रामिंग अभी भी शाब्दिक रूप से भाषा के उपकरणों के दुष्प्रभावों पर आधारित है, जिसका मूल उद्देश्य अलग था, और यहां तक ​​कि सबसे सरल विचारों के आधार पर नतीजतन, मेटलंगुज को व्यक्त करना और पढ़ना मुश्किल है, और टेम्प्लेट कोड को शामिल फ़ाइलों की पुरातन प्रणाली से जोड़ना डेवलपर के लिए जीवन को आसान नहीं बनाता है और संकलक द्वारा संसाधित कोड की मात्रा को कम नहीं करता है।
  
  (दूसरी ओर, बढ़ावा देने और एसटीडी के लिए नियमित अपडेट काफी तुच्छ और अक्सर बेहद उपयोगी निर्माण और अप्रत्याशित समाधान नहीं लाते हैं, जो वास्तव में कम लागत पर अधिक स्पष्ट और कॉम्पैक्ट कोड लिखने की अनुमति देते हैं। हालांकि, नए उत्पादों की धारा इतनी व्यापक, असमान और खराब संरचित है कि सबसे महत्वपूर्ण है। मानक पुस्तकालय में परिवर्धन, यहां तक ​​कि विकल्प / apply_visitor या नीचे उल्लिखित किसी भी तरह के स्पष्ट, यदि किसी विशिष्ट परियोजना के संदर्भ में उनके आवेदन के वैचारिक लाभ प्रासंगिक नहीं हैं आत्म-घटना के लिए, एक खुशहाल घटना की मदद के बिना, वे लंबे समय तक ध्यान से बाहर हो सकते हैं, यदि आप काम के समय के एक महत्वपूर्ण हिस्से को सीधे नए उत्पादों पर नज़र रखने में खर्च नहीं करते हैं, उनके उपयोग के गैर-तुच्छ उदाहरणों का अध्ययन करते हैं और उन्हें एक मौजूदा कोड पर लागू करने के लिए मानसिक प्रयास करते हैं। इस समस्या से निपटने के लिए - C ++ प्रोग्रामर एक C ++ प्रैक्टिस करने वाले हर पांच के लिए रखने के लिए - एक सिद्धांतवादी जो केवल नए उत्पादों की प्राथमिकता के मुद्दों के साथ व्याप्त है, उनका कार्यान्वयन परियोजना में माहौल और चयनात्मक शिक्षा चिकित्सकों। निष्कर्ष: C ++ शुरू न करें - कम डेवलपर्स वाली परियोजनाएं )।
  
• अंत में, निष्पक्ष रूप से सबसे गंभीर समस्या जो बीजीएल बॉयलरप्लेट कोड के साथ काम करते समय होती है । मान लीजिए कि हम कुछ टेम्पलेट एल्गोरिदम का उपयोग कर रहे हैं जो एक ग्राफ़ के माध्यम से एक मार्ग बनाता है और एक तर्क के रूप में ग्राफ जी का प्रतिनिधित्व लेता है। एक विशिष्ट मामले में, यह प्रतिनिधित्व कोने और किनारों पर लगाए गए फिल्टर पर निर्भर करता है $$$F_v$। $$$F_e$और वजन योजना $$$डब्ल्यू$। फ़िल्टर किए गए ग्राफ़ के साथ काम करने के लिए, BGL ऊपर उल्लिखित फ़िल्टर_ग्राफ टेम्पलेट वर्ग प्रदान करता है, इसके लिए भार योजना को संलग्न करने का तरीका उपयोगकर्ता के विवेक पर है। फन का प्रतिनिधित्व करने वाले $$$F_v$। $$$F_e$और $$$डब्ल्यू$कम से कम निम्नलिखित विचार शामिल हो सकते हैं:
  
  
  • सीधे वेटिंग स्कीम का प्रतिनिधित्व करने वाले किसी फंक्शन के लिए एक रैपर और फिल्टर्स का प्रतिनिधित्व करता है (धीरे-धीरे, बिना शुरुआती नुकसान के);
  • इन रैपर पर कैश, बढ़त / नोड सूचकांकों के लिए एज / नोड डिस्क्रिप्टर पर मैपिंग, बिटमैप और मानों के सरणी को संबोधित करते हैं (उपयोग के बिना गति में क्रमिक वृद्धि के साथ, प्रारंभिक नुकसान के बिना);
  • भरे हुए मूल्य सरणियों के लिए नोड / एज डिस्क्रिप्टर का प्रत्यक्ष मानचित्रण (आरंभ की आवश्यकता है, लेकिन पिछले प्रतिनिधित्व के आधार पर बनाया जा सकता है; गति इसकी अधिकतम तक पहुँचती है)।
  
  इस प्रकार, अगर यह एल्गोरिथ्म एक पारंपरिक शैली में लिखा गया था, तो प्रत्येक में कम से कम तीन शाखाओं वाले तीन चयनकर्ता इसके शरीर में दिखाई देंगे (और नए अभ्यावेदन दिखाई देने पर शरीर को समायोजित करने की आवश्यकता)। एल्गोरिथम के शरीर में प्रत्येक शाखा के बाद से, जो ग्राफ़ से गुजरते समय भारी संख्या में निष्पादित होता है, समय की ध्यान देने योग्य हानि होती है, एक ही पारंपरिक शैली के कोड को बनाए रखते हुए इन नुकसानों से बचने की इच्छा प्रतिनिधित्व के विभिन्न संयोजनों के लिए एल्गोरिथ्म के 27+ कार्यान्वयन को जन्म दे सकती है।
  
  मेटाफ्राम शैली आपको इन परेशानियों से बचा सकती है, आपको एल्गोरिथ्म का वर्णन करने वाली एक मेटाफ़ंक्शन का समर्थन करने की अनुमति देता है जो अंतर्निहित रूप से सभी आवश्यक कार्यान्वयन उत्पन्न करता है (और, संभवतः, कुछ, और संभवतः काफी, अनावश्यक की मात्रा यदि रनटाइम-कोड संरचनाएं वास्तव में कुछ प्रकार के संयोजन उत्पन्न नहीं करती हैं, जो ), .
  
  , , inline- , –O2. - ( 1:3 1:5, – , , ).
  
  , . . , ( ) , «» «» . , . : «» «» , «» , «» .
  
  , : , 100% , , «» . ( , , - , , , , , ).
  
• , , , . C++ , -, , .
  
  , , :
  
  

  void type_selector_fun(type_a a, type_b b, ...) { if (condition_1(a, b, ...)) { auto arg = get_type_1_obj(a, b, ...); run_calc(arg, a, b, ...); } else if (condition_1(a, b, ...)) { auto arg = get_type_2_obj(a, b, ...); run_calc(arg, a, b, ...); } else ... } 

  
  इसे निम्नलिखित रूप में <<>> का उपयोग करके कुछ और कॉम्पैक्ट रूप से फिर से लिखा जा सकता है:
  
  

    void type_selector_fun(type_a a, type_b b, ...) { variant<type_1, type_2, ...> arg; if (condition_1(a, b, ...)) { arg = get_type_1_obj(a, b, ...); } else if ... ... apply_visitor([&](auto arg_){run_calc(arg_, a, b, ...); }, arg); } 

  
  इस प्रकार के लेखन का नुकसान विभिन्न प्रकारों की स्पष्ट गणना की आवश्यकता है टाइप 1, टाइप 2, ... वैरिएंट घोषणा में। ये प्रकार बोझिल हो सकते हैं, डिक्लेवल / result_of_t का उपयोग करके रिकॉर्डिंग करना कम बोझिल नहीं हो सकता है।
  
  किसी भी का उपयोग करते समय, प्रकारों को सूचीबद्ध करने की आवश्यकता नहीं होती है, लेकिन एनालॉग apply_visitor प्राप्त करने का कोई तरीका नहीं है।
  
  कुछ टेम्प्लेट फ़ंक्शन मेक_वरिएंट का उपयोग, जो आपको निम्नलिखित प्रकार का कोड लिखने की अनुमति देता है, खुद को सुझाव देता है:
  
  

    auto arg = make_variant ( bind(condition_1, a, b, ...), bind(get_type_1_obj, a, b, ...), bind(condition_2, a, b, ...), bind(get_type_2_obj, a, b, ...), ... ); 

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

    //   variant<...>      //  ,   : type_1, type_2 etc. variant<auto...> get_type_obj(typa_a a, type_b b, ...) { if (condition_1(a, b, ...)) { return get_type_1_obj(a, b, ...); } else if (condition_2(a, b, ...)) { return get_type_2_obj(a, b, ...); } else ... } 

  
  या यहां तक ​​कि:
  
  

    select_value_type(arg) { if (condition_1(a, b, ...)) { arg = get_type_1_obj(a, b, ...); } else ... ... } run_calc(arg, a, b, …); 

  
  उत्तरार्द्ध विकल्प, हालांकि यह पूरी तरह से सी ++ शैली से बाहर खटखटाया गया है, सबसे व्यावहारिक दिखता है, क्योंकि एक से अधिक arg वैरिएबल हो सकते हैं जिसके लिए प्रकार का चयन किया जाता है, और उनके निर्माण के तर्क का अनुमान लगाने का कोई कारण नहीं है ।
  
• उसी स्थिति का फ्लिप पक्ष सहायक संरचनाओं का उपयोग है (उदाहरण के लिए, कैशिंग) एक स्क्रिप्ट को लागू करने वाला जो "टेम्पलेट चर" के नाम के योग्य है, लेकिन उसी नाम के C ++ 14 मानक के विस्तार से भिन्न होता है।
  
  संबंधित कोड कुछ इस तरह दिख सकता है:
  
  

    struct CacheHolder { boost::variant< container<T1>, container<T2>, // ... container<TN>> ct; template<typename T> struct result_type_selector { typedef typename if_c<is_compatible<T, T1>::value, T1, if_c<is_compatible<T, T2>::value, T2, // ... if_c<is_compatible<T, TN>::value, TN, std::decay_t<T>>>>::type type; }; template<typename T> auto get() const -> const container<typename result_type_selector<T>::type>& { return boost::get<container<typename result_type_selector<T>::type>>(ct); } }; 

  
  यहां, ऊपर के रूप में, लंबे निर्माण कैश्ड मूल्य के आयाम (पारदर्शी रूप से कॉलिंग कोड से गुजरने) की परवाह किए बिना एक विशिष्ट नाम से कैश का प्रतिनिधित्व करने वाले चर तक पहुंचने के सरल विचार को व्यक्त करते हैं।
  
  संक्षिप्तता के लिए, कोड उस मामले के लिए दिया जाता है जब केवल एक ही प्रकार सक्रिय हो सकता है, लेकिन व्यवहार में स्थिति अधिक सामान्य होती है जब कई कंटेनर एक साथ मौजूद हो सकते हैं (यह एक ही शैली में आसानी से लागू किया जा सकता है, टुपल और वैकल्पिक का उपयोग करके)।
  
  प्राप्त करने का कार्यान्वयन <...> फ़ंक्शन मानता है कि कॉलिंग कोड का कुछ विचार है कि वह किस प्रकार के कैश्ड मूल्य को एक्सेस करना चाहता है (उदाहरण के लिए, पूर्णांक या फ्लोटिंग पॉइंट)।
  
  कोई कम सामान्य स्थिति नहीं है जहां सटीक प्रकार का मूल्य कॉल करने वाले के लिए महत्वपूर्ण नहीं है। इस मामले में, पिछले पैराग्राफ से select_value_type / apply_visitor स्क्रिप्ट वापस खेली जाती है (मूल्यों की संभावित बहुलता के लिए समायोजित, जिसका अर्थ है प्राथमिकता के अवरोही क्रम में प्रकारों को देखना)।
  
• अब तक, इस पाठ में पीबीजीएल का लगभग कोई उल्लेख नहीं किया गया है। यह पुस्तकालय के इस हिस्से के साथ काम करने के लेखक के गायब होने के छोटे अनुभव (जिसके संबंध में लेखक स्वयं एक निश्चित संदेह के साथ, इस पैराग्राफ में नीचे लिखी गई सभी चीज़ों को संदर्भित करता है, और उसी पर दूसरों को कॉल करता है) द्वारा समझाया गया है। वास्तव में, इस तरह के प्रयोग से कई प्रयोगों पर उबाल आता है, एक ही प्रकार की खोज समस्याओं पर, जो व्यावहारिक डेटा पर एक स्थानीय समाधान को स्मृति में 3-5 बार और समग्र प्रदर्शन में 15-20 बार (इस भयावह आकृति की उत्पत्ति के बारे में बताया गया है) और इसके अलावा निम्नलिखित पैराग्राफ में टिप्पणी की गई है। । वितरित संरचनाओं के साथ काम करने की अधिक जटिलता को देखते हुए, स्थानीय संस्करण के पक्ष में चुनाव ऐसी स्थिति में स्वयं स्पष्ट था।
  
  हमें डेल्टा-चलने वाले एल्गोरिथ्म के एक विशिष्ट उदाहरण का उपयोग करके पीबीजीएल ऑपरेशन के यांत्रिकी की व्याख्या करें। दिज्क्स्ट्रा के एल्गोरिथ्म के इस समानांतर संस्करण में, प्राथमिकता कतार को "बकेट" के एक सरणी के साथ बदल दिया गया है। एक "बाल्टी" में गिरने वाले तत्वों को समानांतर में संसाधित किया जाता है। अपने मूल रूप में, डेल्टा पेसिंग साझा मेमोरी सिस्टम के लिए एक विशिष्ट एल्गोरिथ्म है।
  
  वितरित संस्करण में, निम्न होता है: पीबीजीएल में, जब लोड हो रहा है, तो ग्राफ प्रक्रियाओं के बीच बिखरा हुआ है, और प्रत्येक प्रक्रिया में वर्टेक्स संख्याओं की एक निरंतर श्रृंखला है। इस प्रकार, वैश्विक शीर्ष संख्या से, यह जानना आसान है कि यह किस प्रक्रिया से संबंधित है। तदनुसार, एल्गोरिथ्म के प्रत्येक मोड़ पर प्रत्येक प्रक्रिया "बाल्टी" का एक हिस्सा संग्रहीत करती है जिसमें इस प्रक्रिया से संबंधित कोने होते हैं। सभी प्रक्रियाएँ एक साथ एक समय में "बकेट" के अपने हिस्सों से वर्टिकल को चुनती हैं और प्रोसेस करती हैं, जबकि निम्नलिखित "बकेट" को अपडेट करने की आवश्यकता के बारे में संदेश बाहर भेजती हैं, जो कि अपने स्वयं के वर्टिकल वर्टिकल हैं। यह देखना आसान है कि, ceteris paribus, प्रक्रियाओं की संख्या में वृद्धि से उनके द्वारा भेजे जाने वाले संदेशों की संख्या में वृद्धि होती है। नतीजतन, एल्गोरिथ्म का निष्पादन समय न केवल घट सकता है, बल्कि बढ़ भी सकता है। विशेष रूप से, एक निश्चित संभावना के साथ एक भौतिक मशीन पर इस समस्या को हल करने के लिए कई एमपीआई प्रक्रियाओं के लॉन्च से केवल किसी भी समय लाभ के बिना कुल प्रोसेसर लोड में वृद्धि होगी।
  
  यह ध्यान दिया जाना चाहिए कि डेल्टा पेसिंग सबसे तेजी से वितरित खोज एल्गोरिथ्म है (पुस्तकालय द्वारा समर्थित तीन में से)।
  
  इस प्रकार, यदि ग्राफ पहले से तैयार नहीं है, तो इसे अधिकतम आकार के ब्लॉक, भौतिक ब्लॉक प्रति एक ब्लॉक में विभाजित किया जाना चाहिए। प्रारंभिक तैयारी से हमारा तात्पर्य यहाँ ग्राफ के वर्टिकल को फिर से स्थापित करने से है ताकि पीबीजीएल द्वारा उपयोग की जाने वाली संख्याओं की निरंतर श्रृंखला, यदि संभव हो, तो शिथिल रूप से जुड़े सबग्राफ के अनुरूप हो। METIS, paraMETIS और Zoltan जैसे पैकेज इन उद्देश्यों के लिए उपयोग किए जाते हैं। इस मोड में गतिशील रेखांकन के साथ काम करना मुश्किल है।
  
  सामान्य तौर पर, वर्णित प्रयोगों के परिणामों के अनुसार, लेखक की धारणा थी कि पीबीजीएल क्लस्टर का सामान्य संचालन केवल विशेष संचार उपकरणों के साथ ही संभव है, और यह ऐसे क्लस्टर की नोड्स के रूप में न्यूनतम संख्या में कोर और अधिकतम थ्रेड उत्पादकता के साथ मशीनों का उपयोग करने के लिए समझ में आता है। अपने लेख में ट्रिनिटी के लेखकों का तर्क है कि उनका वितरित भंडारण बहुत अधिक कुशलता से काम करता है - लेखक को इस कथन पर टिप्पणी करना मुश्किल लगता है, लेकिन, उपरोक्त परिस्थितियों को देखते हुए, यह काफी संभव लगता है: पीबीजीएल वास्तुकला उस समय की स्पष्ट मुहर लगाती है जब मल्टी-कोर मशीनों को अभी तक बड़े पैमाने पर वितरण नहीं मिला है।
  
  PBGL सिंगल-थ्रेडेड संस्करण की समस्याओं को भी साझा करता है: कुछ कोड सिंक्रोनाइज़ेशन, प्रलेखन और उदाहरण, सिस्टम की अधिक जटिलता और उपयोगी अनुभव साझा करने के लिए तैयार कम उपयोगकर्ताओं द्वारा बढ़े हुए।
  

बीजीएल और अन्य जानवर

विशिष्ट शिकायतों की एक लंबी सूची को ध्यान में रखते हुए, यह पूछना अनुचित नहीं होगा: क्या लेखक 2019 में नई परियोजनाओं के लिए बीजीएल की सिफारिश कर सकता है। इसका उत्तर यह है: लेखक का मानना ​​है कि इस शैली के पुस्तकालयों और उन पर आधारित अनुप्रयोगों का भविष्य होना चाहिए । एक विशेष परियोजना के लिए एक संदर्भ पुस्तकालय की पसंद के रूप में, हमें गंभीरता से विचार करना चाहिए, ऊपर सूचीबद्ध समस्याओं को देखते हुए नहीं। उत्तर, स्पष्ट रूप से, कई परिस्थितियों पर निर्भर करता है, जिसमें निम्नलिखित पैराग्राफ में सूचीबद्ध लोगों तक सीमित नहीं है, लेकिन:

• किसी परियोजना में रेखांकन के साथ काम करना कार्यक्षमता का आधार है या वैकल्पिक कार्य;
• क्या कोई परियोजना कई अभ्यावेदन के उपयोग के माध्यम से लाभ प्राप्त कर सकती है या इसके लिए काफी कठिन एल्गोरिदम के साथ काम करती है;
• परियोजना के लिए सबसे लाभप्रद प्रकार की संगामिति;
• संगठनात्मक बारीकियों: कर्मचारियों (विशेषकर गणित प्रोग्रामर), आदि के बीच सी ++ में मेटाप्रोग्रामिंग की इच्छा।

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

संभावित विकल्पों के लिए, उनकी सूची में कम से कम निम्नलिखित आइटम शामिल हैं :

विशेष रूप से सामान्य रुचि रेखांकन के साथ काम करने के लिए उन्मुख विभिन्न सॉफ्टवेयर उत्पादों के वर्गीकरण का प्रश्न है। उनकी विविधता, संख्या का उल्लेख नहीं करने के लिए, बहुत बड़ी है। वर्गीकरण को पूरा करने के लिए (और यहां तक ​​कि औपचारिक रूप से सही) का दिखावा किए बिना, हम ग्राफ़िक्स के विकास में निम्नलिखित महत्वपूर्ण क्षेत्रों को उजागर करने का प्रयास कर सकते हैं:

1. ग्राफ DBMS (neo4j, आदि)।
   
   इस तरह के सिस्टम बड़े (वितरित डिस्क) ग्राफ़ पर ट्रांसेक्शनल ऑपरेशन करने पर केंद्रित हैं। हालांकि इस तरह की प्रणाली के एपीआई को अत्यधिक विकसित किया जा सकता है, लेकिन ग्राफ एल्गोरिदम के निष्पादन की गति, जहां तक ​​कोई न्याय कर सकता है, पहली प्राथमिकता नहीं है। सिस्टम पूरे ग्राफ़ को मेमोरी में लोड करने का प्रयास भी नहीं कर सकता है। ग्राफ संशोधन और ट्रैवर्सल के लिए, घोषणात्मक भाषा (SPARQL, साइफ्रे, ग्रेमलिन) का समर्थन किया जाता है। पारंपरिक एसक्यूएल सिस्टम के साथ निरंतरता सुनिश्चित करने के लिए बहुत महत्व जुड़ा हुआ है।
2. मानचित्र में काम करने वाले बड़े डेटा प्रोसेसिंग सिस्टम के ग्राफ़ एक्सटेंशन / प्रतिमान को कम करें (Hadoop के लिए Spark, Pegasus and Giraph में ग्राफएक्स) और स्वतंत्र क्लस्टर सिस्टम ( MS Trinity / MS ग्राफ़ इंजन , GraphLab)। ग्राफ़ पर संचालन करने वाले पहले Google प्रोगेल मॉडल (लेकिन न केवल यह) को लागू करते हैं और बड़े पैमाने पर समानांतर कंप्यूटिंग नोड्स सहित उपयोग के लिए कॉन्फ़िगर किया जा सकता है। कॉरपोरेट सॉफ्टवेयर परियोजनाओं के लिए आधार के रूप में उन दोनों और अन्य का उपयोग किया जा सकता है।
   
   यद्यपि ऐसी प्रणालियों के एपीआई को काफी विकसित किया जा सकता है (अन्य चीजों के अलावा, ग्राफएक्स SPARQL और Cypher का समर्थन करता है), मुख्य फोकस जब उनके साथ काम करना बुनियादी ढांचे की समस्याओं को हल करने पर होता है। ग्राफएक्स में डेटा अपरिवर्तनीयता और सभी ऑपरेशनों के पाइपलाइनिंग में एक पूर्वाग्रह की विशेषता है। एमएस ट्रिनिटी में वर्तमान में उच्च-स्तरीय विधियां शामिल नहीं हैं और नोड्स और किनारों के साथ काम करने के लिए केवल प्राथमिकताओं का एक सेट प्रदान करता है। Hadoop के शीर्ष पर चल रहे सिस्टम, सिद्धांत रूप में, मनमाने ढंग से ग्राफ़ समस्याओं को हल करने के लिए कम उपयोग के हैं।
   
3. वास्तव में सार्वभौमिक टूल लाइब्रेरी जो बड़े पैमाने पर समानांतर वाले (nvGraph, Gunrock) सहित विधियों के अधिक या कम विस्तृत सेट (BGL / PBGL, LEMON आदि) को लागू करते हैं।
   
   उनके आधार पर, एप्लिकेशन सिस्टम बनाए जा सकते हैं जो विशिष्ट विषय क्षेत्रों के लिए ग्राफ एल्गोरिदम को अनुकूलित करते हैं।
4. सार्वभौमिक महत्व (METIS, parMETIS, Zoltran: ग्राफ विभाजन, ग्राफविज़, Gephi: विज़ुअलाइज़ेशन, GraphBLAS: रेखांकन के साथ काम करने के लिए बीजगणितीय एल्गोरिदम)।
   
   कई स्वतंत्र ग्राफ अनुप्रयोगों को सशर्त रूप से इस श्रेणी में सौंपा जा सकता है, जिनके विस्तृत विश्लेषण के लिए बहुत अधिक समय की आवश्यकता होगी। उत्तरार्द्ध में सभी बोधगम्य किस्मों के आवेदन शामिल हैं: शैक्षणिक और वाणिज्यिक, एकल-उपयोगकर्ता और बहु-उपयोगकर्ता, हाल ही में दिखाई दिए और एक दशक से अधिक समय तक मौजूद रहे, आदि।

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

नोट

1. BGL एक विशुद्ध रूप से हेडर लाइब्रेरी नहीं है, लेकिन इस समय एकमात्र कार्यक्षमता जो लिंकिंग की आवश्यकता है, वह है (बल्कि वैकल्पिक) ग्राफविज़ डॉट फाइलों के साथ काम करना। इसलिए, अधिकांश मामलों में, बूस्ट कॉन्फ़िगरेशन में बीजीएल हेडर को शामिल करने के लिए लिब्बोस्ट-ग्राफ के उचित संस्करण के साथ लिंकिंग और स्वचालित लिंकिंग की आवश्यकता नहीं है। इस प्रकार, गैर-हेडर बीजीएल कार्यों द्वारा उपयोग की जाने वाली लिबेरोस्ट-रेगेक्स लाइब्रेरी के साथ सुसंगतता के लिए, प्रोजेक्ट कोड से केवल बूस्ट \ regex.hpp हेडर में प्लग करना सुविधाजनक है, भले ही बाद वाले नियमित अभिव्यक्तियों का उपयोग न करें।
2. अतिरिक्त अराजकता को उन संस्थाओं की उपस्थिति से पेश किया जाता है जिनकी स्पष्ट तुल्यता अंधेरे कमरे में काली बिल्लियों (संभवतः अनुपस्थित) के लिए शिकार को प्रोत्साहित करती है ।
3. इसके विवरण के लिए आगे बढ़ने से पहले (एक विशिष्ट उदाहरण का उपयोग करते हुए जहां यह विशेष रूप से दृढ़ता से और अप्रिय रूप से प्रकट होता है), हम ध्यान दें कि लेखक अपेक्षाकृत कुछ भाग्यशाली लोगों में से है जो एक शक्तिशाली विंडोज ऑपरेटिंग सिस्टम में लोड किए गए प्रोजेक्ट के साथ काम कर रहे हैं और एमएसवीसी कंपाइलर्स की भगवान-सेवित लाइन है। यह संभव है कि नीचे वर्णित परेशानियां संकलक की इस पंक्ति की कलाकृतियां हैं: विभिन्न प्रकार की विशेष परिस्थितियों में * निक्स पर्यावरण में gcc / क्लैंग के साथ तुलनात्मक प्रयोग करना मुश्किल हो जाता है। यदि हां, तो आप केवल अन्य कंपाइलर के उपयोगकर्ताओं को बधाई दे सकते हैं।
4. नरम करने के लिए जो कि कुछ मामलों में, हाल ही में सामने आया कॉन्सेप्ट अगर संभवत: मदद करेगा।
5. हमारे मामले में, इसने राज्य-बचत समारोह पर विशेष ध्यान दिया, जो सुविधा के साथ डिबगिंग की अनुमति देता है, पहले सिस्टम को एक अनुकूलित विधानसभा में वांछित प्रारंभिक स्थिति में लाता है।
6. मेरे व्यवहार में, विभिन्न कारणों से, रनटाइम मापदंडों को टेम्प्लेट तर्कों में बदलने की आवश्यकता थी, और अक्सर मुझे बहुत ही सावधानीपूर्वक, बहुत विस्तृत तरीकों से रूबरू होना पड़ा (C टाइप 98 को बढ़ावा देने वाले टाइपऑफ़ और बूस्ट लैंबडा के प्रेरित होकर) जो सीधे C ++ 98 के लिए बढ़ा। C ++ में प्रोग्रामिंग तकनीक को रिब्यूस के समाधान के रूप में समझें), जिसके बीच स्टार आधे में विभाजित करके तर्क के चयन को चमकता है , लेकिन, सामान्य तौर पर, इस तरह के संचालन के साथ मुख्य समस्याएं हमेशा निर्यात की अक्षमता से जुड़ी थीं दायरे के बाहर चयनित प्रकार, जिसने विदेशी पैटर्न को जन्म दिया।
7. ( — 80 4 50 200 , ) ( ) - . , . , 6-8 — , .
8. , . ( , - , . , , , , , , , ).
9. , , – , , «» (-- ..) . ( , ), , «» , — ( ). , , , - . , , : «» ( ) , «» ( ), , . . , - , « », . , « » ? , , , : – , , , , .
10. . , , .
11. «LIBNAME C++ graph» , stackoverflow. , BGL 500 [boost-graph].