C ऑब्जेक्ट को डिफ़ॉल्ट रूप से बनाने के लिए C ++ को उपयोगकर्ता-प्रदान किए गए डिफ़ॉल्ट निर्माता की आवश्यकता क्यों है?

Question 1

C ++ मानक (धारा 8.5) कहता है:

यदि कोई प्रोग्राम किसी कॉन्स्टेबल-योग्य टाइप T के ऑब्जेक्ट के डिफॉल्ट इनिशियलाइज़ेशन के लिए कहता है, तो T एक क्लास-प्रकार होगा जो यूजर द्वारा प्रदान किया गया डिफॉल्ट कंस्ट्रक्टर है।

क्यों? मैं किसी भी कारण से नहीं सोच सकता कि इस मामले में उपयोगकर्ता द्वारा प्रदान किए गए निर्माण की आवश्यकता क्यों है।

struct B{
  B():x(42){}
  int doSomeStuff() const{return x;}
  int x;
};

struct A{
  A(){}//other than "because the standard says so", why is this line required?

  B b;//not required for this example, just to illustrate
      //how this situation isn't totally useless
};

int main(){
  const A a;
}

Question 2

यह एक दोष माना जाता था (मानक के सभी संस्करणों के खिलाफ) और इसे कोर वर्किंग ग्रुप (सीडब्ल्यूजी) दोष 253 द्वारा हल किया गया था । मानक राज्यों के लिए नया शब्द http://eel.is/c++draft/dcl.init#7 में है

यदि टी का डिफ़ॉल्ट-प्रारंभिक उपयोग टी-के उपयोगकर्ता-प्रदान किए गए कंस्ट्रक्टर (बेस क्लास से विरासत में नहीं मिला है) या यदि हो तो एक क्लास टाइप टी कॉन्स्टेबल-डिफॉल्ट-कंस्ट्रक्टेबल है।

प्रत्येक प्रत्यक्ष गैर-वैरिएंट गैर-स्थैतिक डेटा सदस्य M का T एक डिफ़ॉल्ट सदस्य आरंभीकरणकर्ता है या, यदि M वर्ग प्रकार X (या इसके प्रकार) का है, तो X कांस्टेबल-डिफॉल्ट-कंस्ट्रक्टेबल है,

यदि T कम से कम एक गैर-स्थैतिक डेटा सदस्य के साथ एक संघ है, तो वास्तव में एक भिन्न सदस्य में एक डिफ़ॉल्ट सदस्य initializer है,

यदि T एक संघ नहीं है, तो कम से कम एक गैर-स्थैतिक डेटा सदस्य (यदि कोई हो) के साथ प्रत्येक अनाम संघ सदस्य के लिए, एक गैर-स्थैतिक डेटा सदस्य के पास एक डिफ़ॉल्ट सदस्य आरंभक है, और

टी का प्रत्येक संभावित निर्मित बेस क्लास कॉन्स्टेबल-डिफॉल्ट-कंस्ट्रक्टेबल है।

यदि कोई प्रोग्राम किसी कॉन्स्टेबल-योग्य प्रकार T के ऑब्जेक्ट के डिफॉल्ट-इनिशियलाइज़ेशन के लिए कहता है, तो T एक कॉन्स्टेबल-डिफॉल्टेबल-क्लास टाइप या एरे होगा।

इस शब्द का अर्थ अनिवार्य रूप से यह है कि स्पष्ट कोड काम करता है। यदि आप अपने सभी ठिकानों और सदस्यों को इनिशियलाइज़ करते हैं, तो आप यह कह सकते हैं कि A const a;आप किसी भी कंस्ट्रक्टर को कैसे या किस तरह से जादू करते हैं।

struct A {
};
A const a;

gcc ने 4.6.4 से इसे स्वीकार कर लिया है। क्लेंग ने 3.9.0 के बाद से इसे स्वीकार किया है। विजुअल स्टूडियो भी इसे स्वीकार करता है (कम से कम 2017 में, निश्चित नहीं है कि जल्द ही हो)।

Question 3

कारण यह है कि यदि वर्ग में उपयोगकर्ता-परिभाषित कंस्ट्रक्टर नहीं है, तो वह POD हो सकता है, और POD वर्ग डिफ़ॉल्ट रूप से आरंभीकृत नहीं होता है। इसलिए यदि आप POD की एक कांस्टेबल ऑब्जेक्ट घोषित करते हैं जो कि अनइंस्टॉलिज्ड है, तो इसका क्या उपयोग है? इसलिए मुझे लगता है कि मानक इस नियम को लागू करता है ताकि वस्तु वास्तव में उपयोगी हो सके।

struct POD
{
  int i;
};

POD p1; //uninitialized - but don't worry we can assign some value later on!
p1.i = 10; //assign some value later on!

POD p2 = POD(); //initialized

const POD p3 = POD(); //initialized 

const POD p4; //uninitialized  - error - as we cannot change it later on!

लेकिन अगर आप कक्षा को गैर-पीओडी बनाते हैं:

struct nonPOD_A
{
    nonPOD_A() {} //this makes non-POD
};

nonPOD_A a1; //initialized 
const nonPOD_A a2; //initialized

पीओडी और गैर-पीओडी के बीच अंतर पर ध्यान दें।

उपयोगकर्ता-परिभाषित कंस्ट्रक्टर वर्ग को गैर-पीओडी बनाने का एक तरीका है। ऐसे कई तरीके हैं जिनसे आप ऐसा कर सकते हैं।

struct nonPOD_B
{
    virtual void f() {} //virtual function make it non-POD
};

nonPOD_B b1; //initialized 
const nonPOD_B b2; //initialized

ध्यान दें कि nonPOD_B उपयोगकर्ता-निर्धारित कंस्ट्रक्टर को परिभाषित नहीं करता है। इसे संकलित करें। यह संकलित करेगा:

http://www.ideone.com/h7TsA

और आभासी फ़ंक्शन पर टिप्पणी करें, फिर यह त्रुटि देता है, जैसा कि अपेक्षित है:

http://www.ideone.com/SWk7B

खैर, मुझे लगता है, आपने मार्ग को गलत समझा। यह पहली बार यह कहता है (.58.5 / 9):

यदि किसी ऑब्जेक्ट के लिए कोई इनिशियलाइज़र निर्दिष्ट नहीं किया गया है, और ऑब्जेक्ट (संभवतः cv-योग्य) नॉन-पॉड क्लास प्रकार (या इसके प्रकार) का है, तो ऑब्जेक्ट डिफ़ॉल्ट-आरंभीकृत होगा; [...]

यह गैर-पीओडी वर्ग के बारे में बात करता है जो संभवतः सीवी-योग्य प्रकार है। यदि निर्दिष्ट कोई इनिशियलाइज़र नहीं है, तो गैर-पीओडी ऑब्जेक्ट डिफ़ॉल्ट-आरंभिक होगा। और डिफ़ॉल्ट-आरंभिक क्या है ? गैर-पीओडी के लिए, युक्ति कहती है (/8.5 / 5),

टी प्रकार की एक वस्तु को डिफ़ॉल्ट-प्रारंभिक करने के लिए:
- यदि टी एक गैर-पीओडी वर्ग प्रकार (खंड 9) है, तो टी के लिए डिफ़ॉल्ट निर्माणकर्ता को बुलाया जाता है (और यदि टी कोई सुलभ डिफ़ॉल्ट निर्माता नहीं है, तो आरंभीकरण बीमार हो जाता है);

यह केवल T के डिफ़ॉल्ट निर्माता के बारे में बात करता है , चाहे इसका उपयोगकर्ता-परिभाषित या संकलक-जनित अप्रासंगिक हो।

यदि आप इसे स्पष्ट कर रहे हैं, तो समझें कि आगे की युक्ति क्या कहती है ((/8.5 / 9),

[...]; यदि ऑब्जेक्ट कांस्टेबल-योग्य प्रकार का है, तो अंतर्निहित वर्ग प्रकार में एक उपयोगकर्ता-घोषित डिफ़ॉल्ट निर्माता होगा।

तो इस पाठ का तात्पर्य है, यदि वस्तु कांस्टेबल-योग्य POD प्रकार की है, तो प्रोग्राम बीमार हो जाएगा और इसमें कोई इनिशियलाइज़र निर्दिष्ट नहीं है (क्योंकि POD डिफॉल्ट इनिशियलाइज़ नहीं हैं):

POD p1; //uninitialized - can be useful - hence allowed
const POD p2; //uninitialized - never useful  - hence not allowed - error

वैसे, यह ठीक संकलित करता है , क्योंकि इसका गैर-पीओडी, और डिफ़ॉल्ट-प्रारंभिक किया जा सकता है ।

Question 4

मेरी ओर से शुद्ध अटकलें, लेकिन विचार करें कि अन्य प्रकारों में भी समान प्रतिबंध है:

int main()
{
    const int i; // invalid
}

इसलिए न केवल यह नियम सुसंगत है, बल्कि यह (पुनरावर्ती) इकाईबद्ध const(उप) वस्तुओं को रोकता है :

struct X {
    int j;
};
struct A {
    int i;
    X x;
}

int main()
{
    const A a; // a.i and a.x.j in unitialized states!
}

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

struct A {
    explicit
    A(int i): initialized(true), i(i) {} // valued constructor

    A(): initialized(false) {}

    bool initialized;
    int i;
};

const A a; // class invariant set up for the object
           // yet we didn't pay the cost of initializing a.i

तब शायद हम एक नियम बना सकते हैं जैसे 'कम से कम एक सदस्य को उपयोगकर्ता द्वारा प्रदान किए गए डिफ़ॉल्ट निर्माणकर्ता में समझदारी से आरंभ किया जाना चाहिए', लेकिन इस तरह से मर्फी से बचाव के लिए बहुत अधिक समय व्यतीत करना होगा। C ++ प्रोग्रामर को कुछ बिंदुओं पर भरोसा करने के लिए प्रेरित करता है।

Question 5

मैं C ++ 2018 की बैठक में तैमूर डौलर की बात देख रहा था और मुझे आखिरकार एहसास हुआ कि मानक को यहां एक उपयोगकर्ता-घोषित निर्माता की आवश्यकता है, न कि केवल एक उपयोगकर्ता-घोषित की गई। इसे वैल्यू इनिशियलाइजेशन के नियमों के साथ करना है।

दो वर्गों पर विचार करें: Aएक उपयोगकर्ता-घोषित निर्माता है, Bएक उपयोगकर्ता-प्रदान निर्माता है:

struct A {
    int x;
    A() = default;
};
struct B {
    int x;
    B() {}
};

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

A a;डिफ़ॉल्ट आरंभीकरण है: सदस्य int xअसिंचित है।
B b;डिफ़ॉल्ट आरंभीकरण है: सदस्य int xअसिंचित है।
A a{};मूल्य initialisation है: सदस्य int xहै शून्य initialised ।
B b{};मूल्य आरंभीकरण है: सदस्य int xअसिंचित है।

अब देखें कि जब हम जोड़ते हैं तो क्या होता है const:

const A a;डिफ़ॉल्ट अभिपुष्टि है: यह प्रश्न में उद्धृत नियम के कारण बीमार है ।
const B b;डिफ़ॉल्ट आरंभीकरण है: सदस्य int xअसिंचित है।
const A a{};मूल्य initialisation है: सदस्य int xहै शून्य initialised ।
const B b{};मूल्य आरंभीकरण है: सदस्य int xअसिंचित है।

एक असिंचित constस्केलर (जैसे int xसदस्य) बेकार होगा: इसे लिखना बीमार है (क्योंकि यह है const) और इससे पढ़ना यूबी है (क्योंकि यह अनिश्चित मान रखता है)। तो यह नियम आपको इस तरह की चीज़ बनाने से रोकता है, आपको या तो एक आरंभिक या ऑप्ट-इन जोड़ने के लिए खतरनाक व्यवहार में उपयोगकर्ता द्वारा प्रदान किए गए कंस्ट्रक्टर को जोड़कर।

मुझे लगता है कि [[uninitialized]]जब आप जानबूझकर किसी ऑब्जेक्ट को इनिशियलाइज़ नहीं कर रहे होते हैं, तो कंपाइलर को बताना पसंद करना अच्छा होगा । फिर हम इस कोने के मामले में अपनी कक्षा को सामान्य रूप से डिफ़ॉल्ट रूप से बनाने के लिए मजबूर नहीं होंगे। यह विशेषता वास्तव में प्रस्तावित की गई है , लेकिन अन्य सभी मानक विशेषताओं की तरह, यह किसी भी मानक व्यवहार को अनिवार्य नहीं करता है, केवल संकलक के लिए एक संकेत होने के नाते।

Question 6

बधाई हो, आपने एक ऐसे मामले का आविष्कार किया है जिसमें constघोषणा करने के लिए कोई उपयोगकर्ता परिभाषित कंस्ट्रक्टर नहीं होना चाहिए, जिसका कोई अर्थ नहीं है।

अब आप उस नियम का एक उचित री-वर्डिंग लेकर आ सकते हैं जो आपके मामले को कवर करता है लेकिन फिर भी उन मामलों को बनाता है जो गैरकानूनी होने चाहिए? क्या यह 5 या 6 पैराग्राफ से कम है? क्या यह आसान और स्पष्ट है कि इसे किसी भी स्थिति में कैसे लागू किया जाना चाहिए?

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

सवाल यह है कि क्या कोई सम्मोहक कारण है कि नियम अधिक जटिल होना चाहिए? क्या कोई ऐसा कोड है जिसे लिखना या समझना बहुत मुश्किल होगा, जिसे नियम के अधिक जटिल होने पर बहुत अधिक लिखा जा सकता है?