क्यों __forceinline या उसके पहले से ही छिपा इनलाइन कार्यों के लिए जीसीसी बराबर लागू libcxx करता है?

Question

मैं समझने के लिए वास्तव में क्यों libC++ एक इनलाइन समारोह के लिए दृश्यता मैक्रो गुण यह इनलाइन कार्यों के साथ संबद्ध किया गया है के भाग के रूप __forceinline या __attribute__((__always_inline__)) का उपयोग करता है चाहते हैं।

पृष्ठभूमि के लिए देखें:

• The libcxx visibility design document
• The definition of INLINE_VISIBILITY

इन इनलाइन कार्यों __visibility__("hidden") वैसे भी के रूप में चिह्नित किया जा रहा रहे हैं, तो क्यों आवश्यक अतिरिक्त उन्हें इनलाइन करने के लिए मजबूर करने के लिए संकलक है ?

मैं इसके बारे में थोड़ा सोचा है, और मैं कुछ परिकल्पना है, लेकिन कोई भी मेरे लिए पूरी तरह से संतोषजनक लगता है:

• यह सुनिश्चित करना है कि प्रतीक गलती से ABI का हिस्सा बन नहीं करता है। यदि, लाइब्रेरी का निर्माण करते समय, कंपाइलर ने फ़ंक्शन को इनलाइन करने का विकल्प नहीं चुना है, तो यह संभावित रूप से बाहरी प्रतीक बन सकता है, और इसलिए एबीआई का हिस्सा बन सकता है। लेकिन hidden विशेषता पर्याप्त नहीं होगी? इसी तरह, पुस्तकालय के निर्माण के दौरान कार्य को इनलाइन करने के लिए केवल जरूरी नहीं होगा? उपभोक्ताओं को परवाह नहीं करना चाहिए।
• यह सुनिश्चित करना है कि ओडीआर मुद्दों से बचने के लिए फ़ंक्शन में कभी परिभाषा नहीं है, जहां कंपाइलर लाइब्रेरी में फ़ंक्शन को इनलाइन करने का विकल्प नहीं चुनता है, और क्लाइंट द्वारा उत्पन्न कोड में फ़ंक्शन में इनलाइन नहीं करना चुनता है पुस्तकालय, जिसके परिणामस्वरूप दो अलग-अलग परिभाषाएं होती हैं। लेकिन क्या यह visibility("hidden") का उपयोग करने का अनुमानित (और स्वीकार्य) परिणाम नहीं है?
• यह कुछ libc की ++ डिजाइन के लिए विशिष्ट मानक पुस्तकालय के एक कार्यान्वयन के रूप में है।

मैं यह पूछता हूं क्योंकि मैं एक सी ++ लाइब्रेरी बनाने पर काम कर रहा हूं जिसके लिए मुझे किसी एबीआई को मानकीकृत करने की उम्मीद है, और मैं गाइड के रूप में libC++ का उपयोग कर रहा हूं। अब तक, यह अच्छी तरह से काम किया है, लेकिन इस मुद्दे के कारण कुछ सिर खरोंच हुआ है।

विशेष रूप से, हमारे पास शिकायत करने वाले उपयोगकर्ताओं की रिपोर्ट है कि एमएसवीसी ने __forceinline विशेषता का सम्मान करने से इंकार कर दिया है, जिससे चेतावनियां आती हैं। हमारे प्रस्तावित समाधान केवल __forceinline (या जीसीसी समकक्ष) में शामिल हैं जब लाइब्रेरी बनाना, ऊपर पहले स्पष्टीकरण संभालने INLINE_VISIBILITY के लिए हमारी एनालॉग के विस्तार है।

हालांकि, चूंकि हम पूरी तरह से विश्वास नहीं करते हैं कि हम इनलाइन कार्यों को __forceinline या __attribute__((__always_inline__)) होने के लिए मजबूर करने के पीछे तर्क को समझते हैं, हम इस समाधान को अपनाने में कुछ हद तक संकोच कर रहे हैं।

किसी को भी क्यों libC++ इनलाइन अपने इनलाइन कार्यों के लिए मजबूर करने की जरूरत महसूस करता है, भले ही वे पहले से ही छिपा दृश्यता होने के रूप में सजाया जाता है के लिए एक निश्चित जवाब दे सकते हैं?

Answer 1

मैं के रूप में मैं एक है जो यह किया हूँ इसके समाधान के लिए सबसे अच्छा स्थान में शायद हूँ। और आपको जवाब पसंद नहीं हो सकता है। :-)

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

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

मुझे रोमांच है कि libC++ अपने मूल दायरे से आगे बढ़ गया है और मैं आपको इस प्रयास को जारी रखने में सबसे अच्छा कामना करता हूं। मुझे आपके लक्ष्य में आपकी सहायता करने के लिए मुझे कोई अतिरिक्त जानकारी प्रदान करने में प्रसन्नता हो रही है।