C ++ में कोई आधार वर्ग क्यों नहीं है?


84

क्विक क्वेश्चन: डिजाइन के नजरिए से, ऐसा क्यों है, C ++ में, मदर-ऑफ-ऑल बेस-क्लास नहीं है, आमतौर objectपर अन्य भाषाओं में क्या है?


27
यह वास्तव में एक डिजाइन प्रश्न की तुलना में दार्शनिक प्रश्न का अधिक है। संक्षिप्त उत्तर है "क्योंकि बज्रने स्पष्ट रूप से ऐसा नहीं करना चाहते थे।"
जेरी कॉफिन

4
आपको एक बनाने से कुछ भी नहीं रोक रहा है।
GWW

22
व्यक्तिगत रूप से मुझे लगता है कि एक ही आधार वर्ग से प्राप्त होने वाला सब कुछ एक डिजाइन दोष है। यह प्रोग्रामिंग की एक शैली को बढ़ावा देता है जो इसके लायक होने की तुलना में अधिक समस्याओं का कारण बनता है (जैसा कि आपके पास ऑब्जेक्ट के जेनेरिक कंटेनर होते हैं जो आपको वास्तविक ऑब्जेक्ट का उपयोग करने के लिए ऊपर से मामला करने की आवश्यकता होती है (यह मैं खराब डिजाइन आईएमएचओ के रूप में प्रकट होता है)। क्या मुझे वास्तव में एक कंटेनर चाहिए जो कारों और कमांड ऑटोमेशन ऑब्जेक्ट दोनों को घर कर सके?
मार्टिन यॉर्क

3
@ मर्टिन लेकिन इसे इस तरह से देखें: उदाहरण के लिए, C ++ 0x ऑटो तक, आपको पुनरावृत्तियों के लिए मील-लंबी प्रकार की परिभाषाओं का उपयोग करना था, या एक बार का typedefएस। अधिक सामान्य श्रेणी के पदानुक्रम के साथ, आप बस उपयोग कर सकते हैं objectया iterator
स्लीज़िका

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

जवाबों:


116

स्ट्रॉन्स्ट्रुप के अक्सर पूछे जाने वाले प्रश्नों में निश्चित सत्तारूढ़ पाया जाता है । संक्षेप में, यह किसी भी अर्थ अर्थ को व्यक्त नहीं करता है। इसकी एक लागत होगी। कंटेनर के लिए टेम्प्लेट अधिक उपयोगी होते हैं।

C ++ में यूनिवर्सल क्लास ऑब्जेक्ट क्यों नहीं है?

  • हमें एक की आवश्यकता नहीं है: सामान्य प्रोग्रामिंग ज्यादातर मामलों में सांख्यिकीय रूप से सुरक्षित विकल्प प्रदान करता है। अन्य मामलों को कई विरासत का उपयोग करके नियंत्रित किया जाता है।

  • कोई उपयोगी सार्वभौमिक वर्ग नहीं है: वास्तव में सार्वभौमिक स्वयं का कोई शब्दार्थ नहीं है।

  • एक "सार्वभौमिक" वर्ग प्रकार और इंटरफेस के बारे में मैला सोच को प्रोत्साहित करता है और अतिरिक्त रन-टाइम जाँच की ओर जाता है।

  • एक सार्वभौमिक आधार वर्ग का उपयोग लागत का तात्पर्य करता है: वस्तुओं को बहुरूपी होना चाहिए; इसका मतलब है कि मेमोरी और एक्सेस कॉस्ट। हीप ऑब्जेक्ट्स स्वाभाविक रूप से कॉपी शब्दार्थ का समर्थन नहीं करते हैं। हीप ऑब्जेक्ट सरल scoped व्यवहार का समर्थन नहीं करते (जो संसाधन प्रबंधन को जटिल करता है)। एक सार्वभौमिक बेस क्लास डायनामिक_कास्ट और अन्य रन-टाइम चेकिंग के उपयोग को प्रोत्साहित करता है।


83
हमें किसी आधार / बेस क्लास ऑब्जेक्ट की आवश्यकता नहीं है / हमें किसी भी प्रकार के विचार / नियंत्रण की आवश्यकता नहीं है ...;)
पिस्कोर ने बिल्डिंग :52

3
@Piskvor - LOL मैं संगीत वीडियो देखना चाहता हूं!
बायरन व्हिटलॉक

10
Objects must be heap-allocated to be polymorphic- मुझे नहीं लगता कि यह कथन आम तौर पर सही है। आप निश्चित रूप से स्टैक पर एक पॉलीमॉर्फिक क्लास का एक उदाहरण बना सकते हैं और इसे पॉइंटरोफिक व्यवहार के आधार पर इसके बेस क्लास में से एक को पॉइंटर के रूप में पास कर सकते हैं।
बायरन

5
जावा में, एक संदर्भ-हैं- कास्ट करने के लिए प्रयास करने से Fooएक संदर्भ-हैं- में Barजब Barयह नहीं है कि इनहेरिट Foo, निर्धारणात्मक एक अपवाद फेंकता है। C ++ में, एक पॉइंटर-टू-फू को एक पॉइंटर-टू-बार में डालने का प्रयास सारा कॉनर को मारने के लिए एक रोबोट को समय पर वापस भेज सकता है।
सुपरकैट

3
@supercat इसीलिए हम डायनेमिक_कास्ट <> का उपयोग करते हैं। स्काईनेट से बचने के लिए और रहस्यमय ढंग से चेस्टरफील्ड सोफे को प्रदर्शित करना।
कैप्टन जिराफ

44

आइए पहले यह सोचें कि आप पहले स्थान पर बेस-क्लास क्यों करना चाहते हैं। मैं कुछ अलग कारणों के बारे में सोच सकता हूं:

  1. जेनेरिक संचालन या संग्रह का समर्थन करने के लिए जो किसी भी प्रकार की वस्तुओं पर काम करेगा।
  2. विभिन्न प्रक्रियाओं को शामिल करना जो सभी वस्तुओं (जैसे कि स्मृति प्रबंधन) के लिए सामान्य हैं।
  3. सब कुछ एक वस्तु है (कोई आदिम नहीं!)। कुछ भाषाओं (जैसे ऑब्जेक्टिव-सी) में यह नहीं है, जो चीजों को बहुत गन्दा बनाता है।

ये दो अच्छे कारण हैं कि स्मॉलटाक, रूबी और ऑब्जेक्टिव-सी ब्रांड की भाषाओं में बेस-क्लास हैं (तकनीकी रूप से, ऑब्जेक्टिव-सी में वास्तव में बेस-क्लास नहीं है, लेकिन सभी इरादों और उद्देश्यों के लिए, यह करता है)।

# 1 के लिए, C- ++ में टेम्प्लेट को शामिल करने से एक एकल इंटरफ़ेस के तहत सभी ऑब्जेक्ट्स को एकजुट करने वाली बेस-क्लास की आवश्यकता कम हो जाती है। उदाहरण के लिए:

void somethingGeneric(Base);

Derived object;
somethingGeneric(object);

अनावश्यक है, जब आप पैरामीट्रिक बहुरूपता के माध्यम से सभी तरह से अखंडता बनाए रख सकते हैं!

template <class T>
void somethingGeneric(T);

Derived object;
somethingGeneric(object);

# 2 के लिए, जबकि वस्तुनिष्ठ-सी में, स्मृति प्रबंधन प्रक्रियाएं एक वर्ग के कार्यान्वयन का हिस्सा हैं, और आधार वर्ग से विरासत में मिली हैं, C ++ में मेमोरी प्रबंधन विरासत के बजाय रचना का उपयोग करके किया जाता है। उदाहरण के लिए, आप एक स्मार्ट पॉइंटर रैपर को परिभाषित कर सकते हैं जो किसी भी प्रकार की वस्तुओं पर संदर्भ की गिनती करेगा:

template <class T>
struct refcounted
{
  refcounted(T* object) : _object(object), _count(0) {}

  T* operator->() { return _object; }
  operator T*() { return _object; }

  void retain() { ++_count; }

  void release()
  {
    if (--_count == 0) { delete _object; }
  }

  private:
    T* _object;
    int _count;
};

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

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

तो, आपके प्रश्न का संक्षिप्त उत्तर: C ++ में बेस-क्लास नहीं है, क्योंकि टेम्प्लेट के माध्यम से पैरामीट्रिक पॉलीमॉर्फिज़्म होने पर इसकी आवश्यकता नहीं है।


यह ठीक है! खुशी है कि आप इसे उपयोगी पाया :)
जोनाथन स्टर्लिंग

2
बिंदु 3 के लिए, मैं C # के साथ काउंटर करता हूं। C # में ऐसे आदिम हैं जिन्हें बॉक्सिंग object( System.Object) के लिए किया जा सकता है , लेकिन उन्हें होने की आवश्यकता नहीं है। संकलक के लिए, intऔर System.Int32उपनाम हैं और परस्पर विनिमय के लिए इस्तेमाल किया जा सकता है; जरूरत पड़ने पर रनटाइम बॉक्सिंग संभालती है।
कोल जॉनसन

C ++ में, मुक्केबाजी की कोई आवश्यकता नहीं है। टेम्पलेट्स के साथ, संकलक संकलन समय पर सही कोड उत्पन्न करता है।
रॉब K

2
कृपया ध्यान दें कि इस (पुराने) उत्तर में एक संदर्भ दर्शाया गया है कि स्मार्ट पॉइंटर गिना गया है, C ++ 11 में अब इसका std::shared_ptrउपयोग किया जाना चाहिए।

15

C ++ वैरिएबल के लिए प्रमुख प्रतिमान पास-बाय-वैल्यू है, पास-बाय-रेफ नहीं। सब कुछ एक जड़ से प्राप्त करने के लिए मजबूर Objectकरना उन्हें एक मूल्य ipse facto द्वारा पारित करना होगा।

(क्योंकि मान के रूप में किसी ऑब्जेक्ट को पैरामीटर के रूप में स्वीकार करना, परिभाषा के अनुसार इसे स्लाइस करके और उसकी आत्मा को हटा देगा)।

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


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

IMHO, एक अच्छी भाषा में उन स्थितियों के लिए अलग-अलग प्रकार की विरासत होनी चाहिए, जहाँ एक व्युत्पन्न वर्ग वैध रूप से स्लाइस-बाय-रेफरेंस का उपयोग करते हुए बेस-क्लास ऑब्जेक्ट के रूप में उपयोग किया जा सकता है, जहां इसे स्लाइस-बाय-वैल्यू का उपयोग करके एक में बदल दिया जा सकता है, और वे जहाँ न तो वैध है। उन चीज़ों के लिए एक सामान्य आधार प्रकार होने का मूल्य जो कि कटा हुआ हो सकता है, सीमित होगा, लेकिन कई चीजों को कटा हुआ नहीं किया जा सकता है और इसे अप्रत्यक्ष रूप से संग्रहीत किया जाना चाहिए; इस तरह की चीजें एक आम से प्राप्त होने की अतिरिक्त लागत Objectअपेक्षाकृत मामूली होगी।
सुपरकैट

6

समस्या यह है कि वहाँ सी ++ में इस तरह का है! यह है void। :-) कोई भी पॉइंटर सुरक्षित रूप से निहित हो सकता है void *, जिसमें पॉइंटर्स से लेकर बेसिक प्रकार, बिना वर्चुअल टेबल वाली कक्षाएं और वर्चुअल टेबल वाली कक्षाएं शामिल हैं।

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

तो, वहाँ इस प्रकार है। यह भाषा की निम्न-स्तरीय प्रकृति के कारण बहुत ही न्यूनतम (वास्तव में, खाली) इंटरफ़ेस प्रदान करता है। :-)


सूचक प्रकार और वस्तु प्रकार समान नहीं हैं। आपके पास प्रकार की कोई वस्तु नहीं हो सकती है void
केविन पैंको

1
वास्तव में, यह है कि सी ++ में विरासत कैसे आम तौर पर काम करती है। सबसे महत्वपूर्ण चीजों में से एक यह पॉइंटर और संदर्भ प्रकारों की संगतता है: जहां एक कक्षा के लिए एक पॉइंटर की आवश्यकता होती है, एक व्युत्पन्न वर्ग को एक पॉइंटर दिया जा सकता है। और दो प्रकारों के बीच static_cast पॉइंटर्स की क्षमता एक संकेत है जो वे एक पदानुक्रम में जुड़े हुए हैं। इस दृष्टिकोण से, शून्य निश्चित रूप से C ++ में एक सार्वभौमिक आधार वर्ग है।
एलिओह

यदि आप एक प्रकार का चर घोषित करते हैं, तो voidयह संकलित नहीं होगा और आपको यह त्रुटि मिलती है । जावा में आपके पास एक प्रकार का चर हो सकता है Objectऔर यह काम करेगा। यही अंतर voidऔर "वास्तविक" प्रकार है। शायद यह सच है कि voidसब कुछ के लिए आधार प्रकार है, लेकिन जैसा कि यह किसी भी निर्माता, तरीके या क्षेत्र प्रदान नहीं करता है, यह बताने का कोई तरीका नहीं है कि यह वहां है या नहीं। इस दावे को साबित या अस्वीकृत नहीं किया जा सकता है।
केविन पेंको

1
जावा में प्रत्येक चर एक संदर्भ है। यही अंतर है। :-) (बीटीडब्लू, सी ++ में भी सार कक्षाएं हैं जिन्हें आप एक चर घोषित करने के लिए उपयोग नहीं कर सकते हैं)। और मैंने अपने जवाब में बताया कि शून्य से RTTI प्राप्त करना क्यों संभव नहीं है। तो, सैद्धांतिक रूप से शून्य अभी भी सब कुछ के लिए एक आधार वर्ग है। static_cast एक प्रमाण है, क्योंकि यह केवल संबंधित प्रकारों के बीच कास्ट करता है, और इसका उपयोग शून्य के लिए किया जा सकता है। लेकिन आप सही हैं, शून्य में आरटीटीआई की अनुपस्थिति वास्तव में उच्च स्तर की भाषाओं में आधार प्रकारों से बहुत अलग है।
एलियोह

1
@ Ellioh C ++ 11 मानक .13.9.1p9 से परामर्श करने के बाद, मैं मानता हूं कि voidयह एक प्रकार है (और कुछ हद तक चतुर उपयोग की? : खोज की गई है ), लेकिन यह अभी भी एक सार्वभौमिक आधार वर्ग होने से लंबा रास्ता है। एक बात के लिए, यह "एक अपूर्ण प्रकार है जिसे पूरा नहीं किया जा सकता है," और दूसरे के लिए, कोई void&प्रकार नहीं है ।
bcrist

-2

C ++ एक जोरदार टाइप की गई भाषा है। फिर भी यह हैरान करने वाला है कि इसमें टेम्पलेट विशेषज्ञता के संदर्भ में एक सार्वभौमिक वस्तु प्रकार नहीं है।

उदाहरण के लिए, पैटर्न को लें

template <class T> class Hook;
template <class ReturnType, class ... ArgTypes>
class Hook<ReturnType (ArgTypes...)>
{
   ...
   ReturnType operator () (ArgTypes... args) { ... }
};

जो के रूप में तुरंत किया जा सकता है

Hook<decltype(some_function)> ...;

अब मान लेते हैं कि हम किसी विशेष कार्य के लिए भी यही चाहते हैं। पसंद

template <auto fallback> class Hook;
template <auto fallback, class ReturnType, class ... ArgTypes>
class Hook<ReturnType fallback(ArgTypes...)>
{
   ...
   ReturnType operator () (ArgTypes... args) { ... }
};

विशेष तात्कालिकता के साथ

Hook<some_function> ...

लेकिन अफसोस, भले ही वर्ग टी विशेषज्ञता के पहले किसी भी प्रकार (वर्ग या नहीं) के लिए खड़ा हो सकता है, कोई समकक्ष नहीं है auto fallback(मैं इस संदर्भ में सबसे स्पष्ट सामान्य गैर-प्रकार के रूप में उस वाक्यविन्यास का उपयोग कर रहा हूं) जो किसी के लिए भी खड़ा हो सकता है विशेषज्ञता से पहले गैर-टाइप टेम्पलेट तर्क।

तो सामान्य तौर पर यह पैटर्न टाइप टेम्पलेट तर्क से गैर-टाइप टेम्पलेट तर्क में स्थानांतरित नहीं होता है।

सी ++ भाषा में बहुत सारे कोनों के साथ की तरह, इसका उत्तर "कोई समिति के सदस्य ने नहीं सोचा था"।


यहां तक ​​कि अगर (कुछ ऐसा) आपका ReturnType fallback(ArgTypes...)काम करेगा, तो यह खराब डिजाइन होगा। template <class T, auto fallback> class Hook; template <class ReturnType, class ... ArgTypes> class Hook<ReturnType (ArgTypes...), ReturnType(*fallback)(ArgTypes...)> ...क्या आप चाहते हैं और इसका मतलब है कि Hookलगातार प्रकार
Caleth

-4

C ++ को शुरू में "C with classes" कहा जाता था। यह C # की तरह कुछ और आधुनिक चीजों के विपरीत, C भाषा की प्रगति है। और आप सी ++ को भाषा के रूप में नहीं देख सकते हैं, लेकिन भाषाओं की नींव के रूप में (हां, मुझे स्कॉट मेयर्स की किताब इफेक्टिव सी ++ याद है)।

C अपने आप में भाषाओं का मिश्रण है, C प्रोग्रामिंग लैंग्वेज और इसका प्रीप्रोसेसर है।

C ++ एक और मिश्रण जोड़ता है:

  • वर्ग / वस्तुओं दृष्टिकोण

  • टेम्पलेट्स

  • एसटीएल

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

जैसा कि C ++ C के साथ प्रतिगामी होना चाहता था, डिजाइनर C को C + में अपनी पूरी भाषा में प्रवेश करने की अनुमति देने के लिए बहुत ही अनुज्ञेय थे (कुछ सूक्ष्म अंतर हैं, लेकिन मुझे कोई भी चीज याद नहीं है कि आप C कम्पाइलर का उपयोग कर सकते हैं) C ++ कंपाइलर का उपयोग नहीं कर सका)।


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

@ टिप्पणी: उत्सुकता से, जिस पुस्तक का मैंने केवल एक ही उल्लेख किया है कि वे किसी अन्य भाषा के रूप में भी उल्लेख नहीं करते हैं, यह पूर्वप्रक्रमक है, जिसे आप केवल अलग से मानते हैं। मुझे आपकी बात समझ में आ रही है, क्योंकि प्रीप्रोसेसर पहले अपना इनपुट देता है। लेकिन, एक अस्थायी तंत्र का होना दूसरी भाषा की तरह है जो आपके लिए सामान्यीकरण करता है। आप एक टेम्पलेट सिंटैक्स लागू करते हैं और आपके पास हर एक प्रकार के लिए कंपाइलर जनरेटिंग फ़ंक्शन होंगे। जब आपके पास C में लिखा गया कोई प्रोग्राम हो सकता है और उसका इनपुट C ++ कंपाइलर को दे सकता है, तो यह दो भाषाओं में एक है: C और C ऑब्जेक्ट्स के साथ => C ++
sergiol

एसटीएल, इसे एक ऐड-ऑन के रूप में देखा जा सकता है, लेकिन इसमें बहुत ही व्यावहारिक कक्षाएं और कंटेनर हैं जो टेम्पलेट्स के माध्यम से NATIVELY सी ++ की शक्ति का विस्तार करते हैं। और मैं जो एनम कह रहा था वह नैटिव एनम हैं। जब आप बूस्ट की बात करते हैं, तो आप तीसरे पक्ष के कोड पर भरोसा कर रहे हैं जो भाषा के लिए NATIVE नहीं है। C # में, मुझे इसमें चलने-फिरने और आत्म-स्कोप वाले एनुम होने के लिए कुछ भी शामिल नहीं करना है। C ++ में, एक ट्रिक जो मैं अक्सर इस्तेमाल करता हूं, वह है एनम के अंतिम आइटम को कॉल करना - बिना असाइन किए गए मानों के साथ, इसलिए वे स्वचालित रूप से शून्य से शुरू हो जाते हैं और बढ़ जाते हैं - NUM_ITEMS जैसा कुछ, और यह मुझे ऊपरी सीमा देता है।
सर्गियोल

2
आपके और स्पष्टीकरण के लिए धन्यवाद - मैं कम से कम यह देख सकता हूं कि आप कहां से आ रहे हैं; मैंने कुछ लोगों को शिकायत करते हुए सुना है कि टेम्पलेट का उपयोग करना सीखना अन्य C ++ प्रोग्रामिंग से असहमति महसूस करता है, हालांकि यह निश्चित रूप से मेरा अनुभव नहीं है। मैं अन्य पाठकों को यह बताने के लिए छोड़ दूंगा कि वे आपके द्वारा पेश किए गए अन्य दृष्टिकोणों का क्या करेंगे। चीयर्स।
टोनी डेलारॉय

1
मुझे लगता है कि एक सार्वभौमिक आधार प्रकार के साथ सबसे बड़ी समस्या यह है कि यदि कोई आभासी तरीके नहीं थे तो ऐसा प्रकार बेकार होगा; C ++ ने संरचनात्मक प्रकारों के लिए कोई ओवरहेड नहीं जोड़ना चाहा, जिसमें कोई आभासी विधियां न हों, लेकिन किसी भी प्रकार की कोई भी आभासी विधि वाली प्रत्येक वस्तु में न्यूनतम, सूचक को प्रेषण तालिका में होना चाहिए। यदि कक्षाओं और संरचनाओं में अलग-अलग ब्रह्मांडों का निवास होता है, तो संभव है कि एक सार्वभौमिक वर्ग वस्तु हो सकती है, लेकिन कक्षाएं और संरचनाएं मूल रूप से C ++ में एक ही चीज हैं।
सुपरकैट
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.