मैं जानना चाहता हूं कि C ++ पूर्ण अवधारणाओं के प्रस्ताव और टेम्पलेट बाधाओं (उदाहरण के लिए, Dlang में दिखाई गई बाधाओं या C ++ 1y के लिए नए अवधारणाओं-लाइट प्रस्ताव ) के बीच शब्दार्थ अंतर क्या हैं ।
पूर्ण-संकल्पित अवधारणाएँ, जो कि टेम्पलेट की कमी की तुलना में सक्षम नहीं हैं, क्या नहीं कर सकती हैं?
जवाबों:
निम्नलिखित सूचना पुरानी है। इसे नवीनतम कॉन्सेप्ट लाइट ड्राफ्ट के अनुसार अपडेट करने की आवश्यकता है।
विवशता प्रस्ताव की धारा 3 इसे उचित गहराई में शामिल करती है।
कॉन्सेप्ट प्रपोजल को थोड़े समय के लिए बैक बर्नर पर रखा गया है, इस उम्मीद में कि बाधाओं (यानी कॉन्सेप्ट्स-लाइट) को कम समय के लिए निकाल दिया जा सकता है और लागू किया जा सकता है, वर्तमान में C ++ 14 में कम से कम कुछ करने का लक्ष्य है। बाधाओं का प्रस्ताव अवधारणाओं की एक बाद की परिभाषा के लिए एक चिकनी संक्रमण के रूप में कार्य करने के लिए डिज़ाइन किया गया है। बाधाएं अवधारणा प्रस्ताव का हिस्सा हैं और इसकी परिभाषा में एक आवश्यक बिल्डिंग ब्लॉक हैं।
में सी के लिए संकल्पना पुस्तकालय का डिजाइन ++ , सटन और Stroustrup निम्नलिखित संबंध पर विचार करें:
धारणाएं = बाधाएं + बाधाएं
उनके अर्थों को शीघ्रता से प्रस्तुत करने के लिए:
इसलिए यदि आप अड़चनों (शब्दार्थ गुण) को अड़चन (संश्लिष्ट गुण) से जोड़ते हैं, तो आपको अवधारणाएँ मिलती हैं।
अवधारणाओं-लाइट का प्रस्ताव हमें केवल पहला भाग लाता है, बाधा डालता है, लेकिन यह पूरी तरह से विकसित अवधारणाओं की दिशा में एक महत्वपूर्ण और आवश्यक कदम है।
सिंटैक्स के बारे में सभी बाधाएं हैं । वे हमें संकलित समय में एक प्रकार के सांख्यिकीय रूप से समझदार गुणों का एक तरीका देते हैं, ताकि हम उनके वाक्यगत गुणों के आधार पर टेम्पलेट तर्कों के रूप में उपयोग किए जाने वाले प्रकारों को प्रतिबंधित कर सकें। बाधाओं के लिए वर्तमान प्रस्ताव में, उन्हें तार्किक संयोजकों जैसे &&और का उपयोग करके प्रस्ताव गणना के सबसेट के साथ व्यक्त किया जाता है ||।
आइए कार्रवाई में बाधा पर एक नज़र डालें:
template <typename Cont>
requires Sortable<Cont>()
void sort(Cont& container);
यहाँ हम एक फंक्शन टेम्प्लेट को परिभाषित कर रहे हैं जिसे कहा जाता है sort। नया जोड़ आवश्यकता खंड है । इस फ़ंक्शन के लिए टेम्पलेट तर्कों पर क्लॉज़ के लिए कुछ अवरोधों की आवश्यकता होती है। विशेष रूप से, यह बाधा कहती है कि प्रकार Contएक Sortableप्रकार होना चाहिए । एक साफ बात यह है कि इसे और अधिक संक्षिप्त रूप में लिखा जा सकता है:
template <Sortable Cont>
void sort(Cont& container);
अब यदि आप Sortableइस फ़ंक्शन पर विचार न करने वाले किसी भी चीज़ को पारित करने का प्रयास करते हैं, तो आपको एक अच्छी त्रुटि मिलेगी जो आपको तुरंत बताती है कि जिस प्रकार के लिए कटौती की गई Tहै वह Sortableप्रकार नहीं है । आप सी ++ 11 में इस किया था, तो आप कुछ भयानक त्रुटि से फेंका पड़ा है चाहता हूँ अंदरsort समारोह है कि किसी को कोई मतलब नहीं है।
बाधाएं विधेय प्रकार के लक्षणों के समान हैं। वे कुछ टेम्पलेट तर्क प्रकार लेते हैं और आपको इसके बारे में कुछ जानकारी देते हैं। प्रकार के बारे में निम्नलिखित प्रकार के प्रश्नों का उत्तर देने का प्रयास करता है:
हालांकि, बाधाएं प्रकार के लक्षणों को बदलने के लिए नहीं हैं। इसके बजाय, वे हाथ से काम करेंगे। कुछ प्रकार के लक्षण अब अवधारणाओं के संदर्भ में और कुछ प्रकार के लक्षणों के संदर्भ में परिभाषित किए जा सकते हैं।
तो बाधाओं के बारे में महत्वपूर्ण बात यह है कि वे शब्दार्थ एक कोटा की परवाह नहीं करते हैं। बाधाओं के कुछ अच्छे उदाहरण हैं:
Equality_comparable<T>: जाँचता है कि क्या उस प्रकार ==के दोनों ऑपरेंड के साथ प्रकार है।
Equality_comparable<T,U>: जाँचता है कि क्या ==दिए गए प्रकारों के बाएं और दाएं ऑपरेंड के साथ है
Arithmetic<T>: जाँचता है कि क्या प्रकार एक अंकगणितीय प्रकार है।
Floating_point<T>: जाँचता है कि प्रकार एक अस्थायी बिंदु प्रकार है।
Input_iterator<T>: यह जाँचता है कि इनपुट प्रकारक को समर्थन करने वाले सिंथैटिक ऑपरेशन का समर्थन करता है या नहीं।
Same<T,U>: जाँचता है कि क्या दिए गए प्रकार समान हैं।
आप जीसीसी के विशेष अवधारणाओं-लाइट बिल्ड के साथ यह सब आज़मा सकते हैं ।
अब हम अवधारणाओं-लाइट प्रस्ताव से परे हर चीज में शामिल हो गए हैं। यह भविष्य के मुकाबले और भी अधिक भविष्य है। यहाँ पर बाहर से सब कुछ काफी बदलने की संभावना है।
स्वयंसिद्ध सभी शब्दार्थों के बारे में हैं । वे रिश्तों, अपरिवर्तनों, जटिलता की गारंटी और ऐसी अन्य चीजों को निर्दिष्ट करते हैं। आइए एक उदाहरण देखें।
जबकि Equality_comparable<T,U>बाधा आपको बताएगी कि एक operator== प्रकार है जो लेता है Tऔर U, यह आपको नहीं बताता है कि ऑपरेशन का क्या मतलब है । उसके लिए, हमारे पास स्वयंसिद्ध होगा Equivalence_relation। यह स्वयंसिद्ध कहता है कि जब इन दोनों प्रकारों की वस्तुओं की तुलना operator==देने के साथ की जाती है true, तो ये वस्तुएँ समतुल्य होती हैं। यह बेमानी लग सकता है, लेकिन यह निश्चित रूप से नहीं है। आप आसानी से परिभाषित कर सकते हैं operator==कि इसके बजाय एक की तरह व्यवहार किया operator<। आपको ऐसा करने में बुराई होगी, लेकिन आप कर सकते हैं।
एक अन्य उदाहरण एक Greaterस्वयंसिद्ध है। यह कहना ठीक है और अच्छा है कि दो प्रकार की वस्तुओं की Tतुलना >और <ऑपरेटरों के साथ की जा सकती है , लेकिन उनका क्या मतलब है ? Greaterस्वयंसिद्ध का कहना है कि iff xतो अधिक से अधिक है y, तो yभी कम है x। इस तरह की स्वयंसिद्ध प्रस्तावित विशिष्टता इस प्रकार है:
template<typename T>
axiom Greater(T x, T y) {
(x>y) == (y<x);
}
तो स्वयंसिद्ध प्रश्न निम्नलिखित प्रकारों का उत्तर देते हैं:
यही है, वे पूरी तरह से उन प्रकारों के प्रकार और संचालन के शब्दार्थों से चिंतित हैं। इन चीजों को स्टेटिकली चेक नहीं किया जा सकता है। यदि इसे जाँचने की आवश्यकता है, तो एक प्रकार से यह घोषित किया जाना चाहिए कि यह इन शब्दार्थों का पालन करता है।
यहाँ स्वयंसिद्ध के कुछ सामान्य उदाहरण दिए गए हैं:
Equivalence_relation: यदि दो वस्तुएँ तुलना करती हैं ==, तो वे समतुल्य हैं।
Greater: जब भी x > y, तब y < x।
Less_equal: जब भी x <= y, तब !(y < x)।
Copy_equality: प्रकार xऔर yप्रकार के लिए T: यदि x == y, एक ही प्रकार की नई वस्तु कॉपी निर्माण T{x} == yऔर फिर भी x == y(यानी, यह गैर-विनाशकारी है)।
अब अवधारणाओं को परिभाषित करना बहुत आसान है; वे केवल बाधाओं और स्वयंसिद्ध शब्दों का संयोजन हैं । वे एक प्रकार के वाक्य रचना और शब्दार्थ पर एक सार आवश्यकता प्रदान करते हैं।
एक उदाहरण के रूप में, निम्नलिखित Orderedअवधारणा पर विचार करें :
concept Ordered<Regular T> {
requires constraint Less<T>;
requires axiom Strict_total_order<less<T>, T>;
requires axiom Greater<T>;
requires axiom Less_equal<T>;
requires axiom Greater_equal<T>;
}
पहले ध्यान दें कि टेम्पलेट के प्रकार के Tलिए Ordered, यह Regularअवधारणा की आवश्यकताओं को भी पूरा करना चाहिए । Regularअवधारणा एक बहुत ही बुनियादी आवश्यकताओं कि प्रकार अच्छी तरह से व्यवहार है है - यह, का निर्माण किया जा सकता है नष्ट कर दिया, नकल की और की तुलना में।
उन आवश्यकताओं के अलावा, Orderedआवश्यकता है कि Tएक बाधा और चार स्वयंसिद्ध मिलते हैं:
Orderedप्रकार एक होना चाहिए operator<। यह वैधानिक रूप से जाँच की जाती है इसलिए इसका अस्तित्व होना चाहिए ।xऔर yके प्रकार T:
x < y एक सख्त कुल आदेश देता है।xसे अधिक है y, yसे कम है x, और इसके विपरीत।xसे कम या इसके बराबर है y, yसे कम नहीं है x, और इसके विपरीत।xसे अधिक या इसके बराबर है y, yसे अधिक नहीं है x, और इसके विपरीत।इस तरह की बाधाओं और स्वयंसिद्ध शब्दों का संयोजन आपको अवधारणाएँ देता है। वे एल्गोरिदम के साथ उपयोग के लिए अमूर्त प्रकार के लिए वाक्यात्मक और अर्थ संबंधी आवश्यकताओं को परिभाषित करते हैं। एल्गोरिदम को वर्तमान में यह मानना होगा कि उपयोग किए जाने वाले प्रकार कुछ संचालन का समर्थन करेंगे और कुछ शब्दार्थों को व्यक्त करेंगे। अवधारणाओं के साथ, हम यह सुनिश्चित करने में सक्षम होंगे कि आवश्यकताओं को पूरा किया जाए।
में नवीनतम अवधारणाओं डिजाइन , संकलक केवल जाँच करेगा कि एक अवधारणा के वाक्यात्मक आवश्यकताओं टेम्पलेट तर्क द्वारा पूरा कर रहे हैं। स्वयंसिद्ध अनियंत्रित छोड़ दिए जाते हैं। चूँकि स्वयंसिद्ध शब्दार्थ को निरूपित करते हैं जो सांख्यिकीय रूप से मूल्यांकन योग्य नहीं होते हैं (या अक्सर पूरी तरह से जांचना असंभव है), एक प्रकार के लेखक को स्पष्ट रूप से यह बताना होगा कि उनका प्रकार किसी अवधारणा की सभी आवश्यकताओं को पूरा करता है। यह पिछले डिजाइनों में अवधारणा मानचित्रण के रूप में जाना जाता था लेकिन तब से हटा दिया गया है।
यहाँ अवधारणाओं के कुछ उदाहरण दिए गए हैं:
Regular प्रकार निर्माण योग्य, विनाशकारी, प्रतिलिपि योग्य हैं, और उनकी तुलना की जा सकती है।
Orderedप्रकार का समर्थन करते हैं operator<, और एक सख्त कुल आदेश और अन्य क्रमबद्ध शब्दार्थ है।
Copyableप्रकार, प्रतिलिपि बनाने योग्य, विनाशकारी हैं, और यदि xसमान है yऔर xप्रतिलिपि बनाई गई है, तो प्रतिलिपि भी समान के बराबर होगी y।
Iteratorप्रकार उनसे संबंधित नहीं है प्रकार value_type, reference, difference_type, और iterator_categoryखुद को कुछ अवधारणाओं को पूरा करना होगा जो। उन्हें भी समर्थन करना चाहिए operator++और निष्क्रिय होना चाहिए ।
बाधाएं C ++ की एक पूर्ण अवधारणा सुविधा की ओर पहला कदम हैं। वे एक बहुत ही महत्वपूर्ण कदम हैं, क्योंकि वे प्रकारों की सांख्यिकीय रूप से लागू करने योग्य आवश्यकताओं को प्रदान करते हैं ताकि हम बहुत क्लीनर टेम्पलेट फ़ंक्शन और कक्षाएं लिख सकें। अब हम कुछ कठिनाइयों और कुरूपता std::enable_ifऔर उसके रूपक मित्रों के कुरूपता से बच सकते हैं ।
हालाँकि, ऐसी कई चीजें हैं जो अड़चन का प्रस्ताव नहीं करती हैं:
यह एक अवधारणा परिभाषा भाषा प्रदान नहीं करता है।
बाधाएं अवधारणा मानचित्र नहीं हैं। उपयोगकर्ता को कुछ बाधाओं को पूरा करने के लिए विशेष रूप से अपने प्रकार को एनोटेट करने की आवश्यकता नहीं है। वे संकलित रूप से उपयोग की जाने वाली सरल संकलन-समय भाषा की विशेषताएँ हैं।
टेम्प्लेटों के कार्यान्वयन को उनके टेम्प्लेट तर्कों पर बाधाओं द्वारा विवश नहीं किया जाता है। यही है, यदि आपका फ़ंक्शन टेम्प्लेट विवश प्रकार के ऑब्जेक्ट के साथ कुछ भी करता है जो इसे नहीं करना चाहिए, तो कंपाइलर के पास इसका निदान करने का कोई तरीका नहीं है। एक पूरी तरह से चित्रित अवधारणा प्रस्ताव ऐसा करने में सक्षम होगा।
बाधाओं का प्रस्ताव विशेष रूप से तैयार किया गया है ताकि इसके शीर्ष पर एक पूर्ण अवधारणा प्रस्ताव पेश किया जा सके। किसी भी भाग्य के साथ, यह संक्रमण काफी सहज सवारी होना चाहिए। अवधारणा समूह C ++ 14 (या इसके तुरंत बाद एक तकनीकी रिपोर्ट में) के लिए बाधाओं का परिचय दे रहे हैं, जबकि पूर्ण अवधारणाएं C ++ 17 के आसपास कुछ समय में उभरना शुरू कर सकती हैं।
हाल ही के (मार्च 12) के खंड 2.3 में "अवधारणाओं के बारे में '' लाइट 'क्या है" भी देखें (12 मार्च) टेलीकॉन मिनट्स और चर्चा का रिकॉर्ड, जो उसी दिन यहां पोस्ट किए गए थे: http://isocpp.org/blog/2013/03 / new-paper-n3576-sg8-concept-teleconference-minutes-2013-03-12-हर्ब-सटर ।
मेरे 2 सेंट:
अवधारणाओं-लाइट का प्रस्ताव टेम्पलेट कार्यान्वयन के "प्रकार की जाँच" करने के लिए नहीं है । यानी, कॉन्सेप्ट-लाइट टेम्पलेट तात्कालिकता साइट पर (विशेषकर) इंटरफ़ेस संगतता सुनिश्चित करेगा। कागज से उद्धरण: "अवधारणा लाइट सी ++ का एक विस्तार है जो टेम्पलेट तर्कों को विधेय के उपयोग की अनुमति देता है"। और बस। यह नहीं कहता है कि टेम्पलेट बॉडी की जाँच की जाएगी (अलगाव में)। इसका मतलब है कि जब आप अवधारणाओं-लाइट के बारे में बात कर रहे हैं तो आर्कटाइप्स की कोई प्रथम श्रेणी की धारणा नहीं है । द्वीपसमूह, अगर मुझे सही ढंग से याद है, अवधारणाओं में-भारी प्रस्ताव ऐसे प्रकार हैं जो टेम्पलेट के कार्यान्वयन को संतुष्ट करने के लिए कोई कम और अधिक नहीं प्रदान करते हैं ।
संकलक द्वारा समर्थित सिंटैक्स चाल के एक बिट के साथ अवधारणाओं-लाइट का उपयोग महिमामंडित कॉन्स्ट्रेक्स कार्यों का उपयोग करता है। लुकअप नियमों में कोई बदलाव नहीं।
प्रोग्रामर को अवधारणा मानचित्र लिखने की आवश्यकता नहीं होती है।
अंत में, फिर से उद्धृत करते हुए "बाधाओं का प्रस्ताव सीधे तौर पर सिमेंटिक के use उद्धरण या उपयोग को संबोधित नहीं करता है; यह केवल सिंटैक्स की जाँच पर लक्षित है।" इसका मतलब है कि स्वयंसिद्ध क्षेत्र (अब तक) के दायरे में नहीं हैं।