2017-10-22 5 views
15

सी ++ 17 की अनुमति देता है स्थिर सदस्य चर इस प्रकार परिभाषित किया जाना:स्थिर इनलाइन चर पर "इनलाइन" क्यों आवश्यक है?

class X { 
    public: 
    static inline int i = 8; 
}; 

inline विनिर्देश की आवश्यकता होती है के पीछे तर्क क्या है? प्रोग्रामर को

static int i = 8; 

कक्षा में लिखने की अनुमति क्यों न दें?

+1

चेक इस [प्रश्न और उत्तर] (https://stackoverflow.com/questions/3409428/putting-class-static-members-definition-into-cpp-file-technical-limitation), यह आप दे सकते हैं "क्यों" में कुछ अंतर्दृष्टि। –

उत्तर

12

inline के बिना, यह स्पष्ट रूप से केवल एक घोषणा के रूप में कहा गया है। अपने वर्ग परिभाषा [class.static.data]/2

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

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

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

उदाहरण के लिए, इस वैध सी ++ 03 वर्ग परिभाषा पर विचार करें:

struct foo { 
    static const int n = 3; 
    double bar[n]; 
}; 

nbar की हद तक परिभाषित करने के लिए एक निरंतर अभिव्यक्ति के रूप में इस्तेमाल किया जा सकता है, और यह माना जाता है एक ओडीआर उपयोग नहीं कर रहा है। आजकल हम इसे constexpr के रूप में लिखेंगे, हालांकि उपर्युक्त अभी भी वैध है। लेकिन वहां मामले n हो सकते हैं odr-used (इसके पते को लिया गया है, या इसके लिए संदर्भित संदर्भ इत्यादि) होना चाहिए। वे शायद कई नहीं है, और शायद आम नहीं हैं, लेकिन कुछ एपीआई पागल आवश्यकताओं है कि कुछ अनुवाद इकाई में प्रदर्शित करने के लिए इस

const int foo::n; 

की जरूरत महसूस खत्म होता है।

अब, static inline int i = 8; अचानक inline था, उपरोक्त परिभाषा (जो मौजूदा कोड बेस में है) एक ओड्र-उल्लंघन होगा। अब पहले अच्छी तरह से गठित कोड, खराब गठित है। इसलिए यहां केवल स्पष्टinline को प्रभावी होने की अनुमति देना सर्वोत्तम है, क्योंकि केवल नए कोड में वास्तव में यह होगा।


एक बहस कर सकते static constexpr चर एक ही मुद्दा हो सकता है (और अभी तक वे परोक्ष इनलाइन हैं)। लेकिन आईआईआरसी ने उनके मूल शब्दकोष को मौजूदा कोड को तोड़ने के बिना इस बदलाव की अनुमति दी। यह अनिवार्य रूप से पहले से ही "इनलाइन" नाम से सब कुछ था।

+2

यह उत्तर "समस्याग्रस्त" व्यवहार के वास्तविक उदाहरण के साथ बेहतर होगा – Yakk

+0

ओपी का कोड सुझाव पहले से ही खराब है, इसलिए परिवर्तन मौजूदा कोड को तोड़ नहीं देगा। लेकिन यह कुछ हद तक असंगत –

+0

@ एमएम - ओपी का कोड होगा। लेकिन वही उपचार ** कॉन्स ** डेटा सदस्यों पर लागू होना होगा, जो अच्छी तरह से गठित हैं। किसी भी तरह से, मैं विस्तार की प्रक्रिया में हूँ। बस एक पल – StoryTeller

संबंधित मुद्दे