क्या सी ++ में ऑपरेटर अधिभार अधिक मूल्यवान हैं?

Question

मेरे अनुभव सी ++ को पढ़ाने में, ऑपरेटर ओवरलोडिंग उन विषयों में से एक है जो छात्रों को सबसे दुःख का कारण बनती हैं। स्टैक ओवरफ्लो पर यहां प्रश्नों को भी देख रहे हैं: उदाहरण के लिए, + ऑपरेटर बाहरी या सदस्य बनाएं? समरूपता को कैसे संभालें, इत्यादि, ऐसा लगता है कि यह बहुत परेशानी है।

जब मैं सी ++ से जावा में स्थानांतरित हो गया, तो मुझे चिंता थी कि मैं उस क्षमता को याद करूंगा, लेकिन ऑपरेटरों जैसे अपवाद के साथ [] या(), मुझे वास्तव में ऑपरेटरों को अधिभारित करने की आवश्यकता महसूस नहीं हुई है। वास्तव में, मुझे लगता है कि उनके बिना कार्यक्रम अधिक पठनीय हैं।

नोट: मैंने इसे एक समुदाय विकी के रूप में रखा है। आइए इस पर चर्चा करें। मैं राय सुनना चाहता हूँ।

Answer 1

अधिभारित ऑपरेटर मसाले की तरह हैं। थोड़ा बेहतर कुछ कर सकता है; बहुत अधिक इसे unpalatable बना सकते हैं।

Answer 2

अधिक भार है कि हर सी ++ प्रोग्रामर, के बारे में पता होना चाहिए, भले ही वे स्वीकार नहीं करते के कुछ उदाहरण:

• ऑपरेटर =() आदेश सी ++ वस्तुओं के मूल्यों की तरह व्यवहार करने के लिए अनुमति देने के लिए आवश्यक है।
• ऑपरेटर ->() आदेश स्मार्ट संकेत
को लागू करने के लिए आवश्यक है
• ऑपरेटर < <() और ऑपरेटर >>() iostream ढांचे
• ऑपरेटर < (में प्रकार एकीकृत करने के लिए आवश्यक हैं) डिफ़ॉल्ट रूप से प्रयोग किया जाता है जब) मानक पुस्तकालय कंटेनर में संग्रहीत
• ऑपरेटर (वस्तुओं() की तुलना मानक पुस्तकालय एल्गोरिदम
• ऑपरेटर ++() द्वारा इस्तेमाल किया functors लागू करने के लिए प्रयोग किया जाता है, तो आप अपने खुद के इटरेटर लागू उपलब्ध होने की उम्मीद है

Answer 3

मुझे लगता है कि यह वास्तव में उपयोग के मामले पर निर्भर करता है। ऐसे कई प्रकार के वर्ग हैं जिनके लिए ऑपरेटरों की आवश्यकता होती है। उदाहरण के लिए, स्मार्ट पॉइंटर्स बिना > और * ऑपरेटर के बिना बेकार होंगे।

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

if (point1 > point2) ... 

बस भार से

if (point1.Compare(point2) < 0) ... 

मैं अन्य ऑपरेटरों के लिए कम उपयोग लगता है, हालांकि कभी-कभी डाली काम में आता बेहतर लग रहा है।

Answer 4

जैसा कि नील अपने जवाब में बताता है, ऑपरेटर ओवरलोडिंग अच्छी ऑब्जेक्ट उन्मुख सी ++ मुहावरे सीखने के लिए एक आवश्यक विषय है। मैं छात्रों को सावधानी बरतता हूं कि यदि आप बेवकूफ सम्मेलनों के बाद अधिभारित ऑपरेटरों को लागू नहीं करते हैं, तो यह बहुत छोटी और अप्रत्याशित व्यवहार का कारण बन सकता है। ऑपरेटर ओवरलोडिंग रचनात्मक होने का एक अच्छा समय नहीं है।

Answer 5

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

यह सब कुछ है।
कभी-कभी मैंने अन्य ऑपरेटरों का उपयोग किया है, लेकिन यह मेरे गणित के उपयोग के लिए था।

भी तार्किक ऑपरेटरों (& &, ||) के साथ सावधान रहना चाहिए - हम मानक अर्थ के साथ अंतर होगा:

ptr && ptr->method() 

अन्य अर्थ हो सकता था अगर हम ऑपरेटर & & अतिभारित है।

Answer 6

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

सचमुच, जब तक मुझे लाइब्रेरी की आवश्यकता नहीं होती तब तक मैं एक ऑपरेटर को अधिभारित नहीं करूँगा। यह सिर्फ पाठक को यह पता लगाने के लिए बहुत कठिन बनाता है कि क्या हो रहा है।

Answer 7

ओवरलोडेड ऑपरेटरों के बारे में शिकायत करना जितना आसान है, जब तक वे आश्चर्यजनक तरीके से कार्य नहीं करते हैं, मुझे वास्तव में समस्या दिखाई नहीं देती है। हां वहाँ बुरे उदाहरण हैं (यहां तक ​​कि एसटीएल में भी)। उदाहरण के लिए auto_ptr का असाइनमेंट ऑपरेटर देखें। कुछ ऑपरेटर ओवरलोड करना, जैसे &&, || और , लगभग हमेशा खराब होने जा रहा है। लेकिन अधिकांश भाग के लिए, ऑपरेटरों को वह विज्ञापन करें जो वे विज्ञापित करते हैं और कोई वास्तविक समस्या नहीं है।

कुछ अजीब काम करने के लिए operator+ अधिभार को खराब करने का बुरा अभ्यास है, लेकिन यह उतना ही बुरा है जितना कि आप अपनी कक्षा में "जोड़ें" नामक एक विधि डालते हैं जो ऑब्जेक्ट को डिस्क पर क्रमबद्ध करता है।

Answer 8

यह सुविधा के लिए एक अच्छा है लेकिन एक आवश्यक नहीं है। कई मामलों में मुझे उनके लाभों की तुलना में अधिक भ्रमित लगता है। जेरेडपार्स उदाहरण की तरह, .compare फ़ंक्शन मेरे लिए '>' से अधिक स्पष्ट है। एक व्यक्ति सीधे देखता है कि बिंदु 1 एक वस्तु है और एक प्राचीन डेटा प्रकार नहीं है। मुझे libs में ओवरलोडेड ऑपरेटर पसंद हैं जो मैं उपयोग करता हूं लेकिन अपने कोड में मैं उन्हें बहुत ही कम इस्तेमाल करता हूं।

संपादित करें: फ़ंक्शन नाम की मेरी पसंद असंगत है। बदलें .greaterThan के साथ तुलना करें इसे स्पष्ट बनाता है। मेरा मतलब यह है कि मेरे लिए ऑब्जेक्ट करने के लिए बाध्य एक फ़ंक्शन नाम ऑपरेटर से अधिक स्पष्ट है जिसका ऑब्जेक्ट के साथ पहले रूप में कोई संयोजन नहीं है। Imho एक अच्छी तरह से चुने गए समारोह का नाम पढ़ने के लिए आसान है।

Answer 9

मुझे वास्तव में सी ++ में गैर-निर्मित प्रकारों के लिए अंकगणितीय ऑपरेटरों को अधिभारित करने की क्षमता पसंद है। लेकिन केवल अंकगणित-जैसे व्यवहार के प्रकार के लिए; उदाहरण के लिए निश्चित बिंदु कक्षाएं, 3 डी वेक्टर कक्षाएं, जटिल संख्या कक्षाएं, मनमाने ढंग से लंबाई "बिग्नम" कक्षाएं।मैंने जावा में समान कोड लिखा है और a+b के बजाय a.Add(b) जैसी चीजें लिखकर नाराज हो गया है। आपको याद है, मैं प्रशिक्षण के द्वारा गणितज्ञ हूं; मुझे लगता है कि ऑपरेटर ओवरलोडिंग आपको वास्तव में एक को लागू किए बिना सी ++ में डोमेन-विशिष्ट-भाषा की भलाई का थोड़ा सा हिस्सा प्राप्त करने देता है।

लेकिन यह वास्तव में मुझे गुस्सा दिलाती है जब मैं देख रहा हूँ, उदा, operator+ जो बेहतर operator<< द्वारा किया जा होगा या एसटीएल .push_back() तरह पैटर्न (कुशल लेकिन अच्छी तरह से स्थापित iostream सम्मेलन के बाद) कार्यक्षमता के साथ अतिभारित किया जा रहा।

operator() के लिए ... boost::bind & boost::function की खोज पोस्ट मैं मज़दूरों के बिना जीवन की कल्पना नहीं कर सकता। और स्मार्ट पॉइंटर्स operator*, operator-> इत्यादि के बिना लगभग सुविधाजनक नहीं होंगे

Answer 10

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

स्मार्ट पॉइंटर्स ऑब्जेक्ट्स पर भरोसा करते हैं जो डेरफ़्रेंसिंग ऑपरेटर को अधिभारित करने में सक्षम होते हैं ताकि वे पॉइंटर्स की तरह व्यवहार कर सकें।

ऑपरेटर ओवरलोडिंग सी ++ प्रोग्रामिंग सहनशील बनाने के लिए बेहद महत्वपूर्ण है। क्योंकि यह जटिल है, मुझे बस यह नहीं दिख रहा है। यह आपके स्वयं के कार्य को बनाने से कहीं अधिक जटिल नहीं है, जो लोग आम तौर पर काफी आसान पाते हैं। यदि आप इसे "गुणा करें" नाम देते हैं तो यह एक फ़ंक्शन है, यदि आप इसे "ऑपरेटर *" नाम देते हैं, तो यह एक ऑपरेटर है। लेकिन शरीर में कोड बिल्कुल वही है।

बेशक ऑपरेटर कभी-कभी दुर्व्यवहार करते हैं। और < < या >> सीमा रेखा स्वीकार्य हो सकती है, लेकिन वे इतनी आम तौर पर ज्ञात और उपयोग की जाती हैं कि मुझे लगता है कि यह उचित है।

यदि आप सी # जैसे कुछ में ऑपरेटर ओवरलोडिंग के बारे में पूछे तो, मैं खुशी से उनके बिना करूँगा। उनका कार्यान्वयन बहुत अधिक अजीब है, वे जेनेरिक के साथ काम नहीं करते हैं, और वे सी ++ का उपयोग करने वाली सभी अच्छी और सुविधाजनक चाल को सक्षम नहीं करते हैं।

Answer 11

ओवरलोडेड ऑपरेटर कुछ चीजों को करने के संभावित तरीके हैं, लेकिन दुरुपयोग के लिए बहुत ही आसान हैं।

<< और >> ओवरलोडिंग ऑपरेटरों को नई प्रकार की धाराओं, आई/ओ के लिए नई वस्तुओं, और दोनों में सी ++ की धाराओं का विस्तार करना आसान बनाता है। -> ओवरलोडिंग स्मार्ट पॉइंटर्स को सी ++ पॉइंटर्स के लिए लगभग एक ड्रॉप-इन प्रतिस्थापन बनाता है। ओवरलोडेड ऑपरेटर एक स्ट्रिंग कॉन्सटेनेशन ऑपरेटर बनाना संभव बनाता है, और int एस की तरह सिंटैक्टिक रूप से संख्याओं के नए प्रकार का निर्माण करना संभव बनाता है। उन्हें पुस्तकालयों में चीजें करना संभव बनाता है जिसके लिए अन्य भाषाओं में भाषा-स्तर परिवर्तन की आवश्यकता होती है।

उनके पास उनकी सीमाएं हैं। एक्सपोनिएशन के लिए कोई ऑपरेटर उपयुक्त नहीं है। केवल एक गुणा ऑपरेटर है, और कुछ मामलों में गुणा करने के लिए एक से अधिक तरीके हैं (3 डी वैक्टर के साथ, उदाहरण के लिए, कम से कम डॉट और क्रॉस उत्पाद हैं)। &&, ||, और अल्पविराम ऑपरेटर अपनी अंतर्निहित कार्यक्षमता को दोहराने नहीं कर सकते हैं, क्योंकि उनके पास शॉर्ट-सर्किट मूल्यांकन और अनुक्रम बिंदु नहीं हो सकते हैं।

और, ज़ाहिर है, उनका दुरुपयोग किया जा सकता है।उदाहरण के लिए, कोई भाषा आवश्यकता नहीं है, कि अंकगणितीय ऑपरेटरों को अंकगणित जैसी कुछ भी काम करना है। मैंने एक एसक्यूएल नोटेशन के साथ आने के प्रयास में भयानक चीजें देखी हैं जिन्हें किसी ने सोचा था। एक सी ++ प्रोग्राम में जो बुरी तरह लिखा गया था, यह जानना असंभव है कि a = x * y; क्या है, क्योंकि यह a.operator=(x.operator*(y)); है, या शायद a.operator=(operator*(x, y)); या कुछ हो सकता है, और ऑपरेटर फ़ंक्शंस कुछ भी करने के लिए लिखा जा सकता है।

सी ++ को डिजाइन करने में बजेर्न स्ट्राउस्ट्रप का इरादा दुरुपयोग की संभावना के बावजूद उपयोगी सुविधाओं को शामिल करना था, जबकि जेम्स गोस्लिंग का जावा डिजाइन करने का इरादा अत्यधिक उपयोग करने योग्य सुविधाओं को बाहर करना था, भले ही वे कुछ उपयोगी थे। यह मुझे स्पष्ट नहीं है कि इनमें से कोई भी दर्शन सही या गलत है, लेकिन वे अलग हैं।

जावा उन परिस्थितियों से बचने के लिए डिज़ाइन किया गया था जो आम तौर पर ऑपरेटर ओवरलोडिंग, एकाधिक विरासत और रन-टाइम प्रकार की कटौती जैसे कुछ सी ++ सुविधाओं के लिए कॉल करते हैं, इसलिए उन्हें अक्सर याद नहीं किया जाता है। चाहे यह अच्छा या बुरा हो या न ही मुझे कुछ पता हो।

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

Answer 12

मुझे नहीं लगता कि ऑपरेटर ओवरलोडिंग एक बुरा विचार था। मुझे लगता है कि निहित रूपांतरण करना डिफ़ॉल्ट व्यवहार एक बुरा विचार था। और ऑपरेटर ओवरलोडिंग के साथ संयोजन में डिफ़ॉल्ट अंतर्निहित रूपांतरण वास्तव में खराब विचार है।

पूरी तरह से निहित रूपांतरण को दूर करें - या इसे "निहित" कीवर्ड पर निर्भर करें - और भाषा को this one जैसे अनगिनत लेखों में संभावित नुकसान और गेटचास की चर्चा कभी नहीं हुई होगी।

Answer 13

ऑपरेटर में से एक जो आप बेहतर अधिभार से बचने के लिए बेहतर था conversion operator है। यह इस तरह के अप्रत्याशित परिणाम की ओर जाता है कि यहां तक ​​कि एसटीएल यह ओवरलोड नहीं पसंद करते हैं और बजाय पसंद समारोह शैली रूपांतरण:

std::string str = "foo"; 
char *ch = str.c_str(); //rather than char *ch = str.operator *char(); 

Answer 14

मैं, जावा में अतिभारित ऑपरेटरों होने विशेष रूप से निम्न स्थितियों में याद आती है:

एक वर्ग है कि एक एल्गोरिदम या एक मज़ेदार: (रणनीति पैटर्न, जिम्मेदारी की श्रृंखला, इंटरप्रेटर, आदि)। प्राकृतिक चीज ओप() को अधिभारित करना है; इसके बजाए, प्रत्येक प्रोग्रामर कार्यों के लिए नाम (अक्सर असंगत और इस प्रकार भ्रमित) के साथ आता है: "eval", "मूल्यांकन", "ऑपरेशन", "doIt" इत्यादि। इसलिए स्पष्टता कम हो जाती है, क्योंकि इन नामों को हम उपयोग करने के लिए मजबूर हैं उनके अर्थ को स्पष्ट मत बनाओ।

एक वर्ग जिस पर दूसरे प्रकार का रूपांतरण है: सी ++ में ऑपरेटर टाइप() है, और वास्तविक रूपांतरण के लिए और वांछित वर्ग के आंतरिक सदस्य को प्राप्त करने के लिए दोनों काम करता है। दूसरे मामले जावा में एक बहुत ऊपर आता है जब एक वर्ग को अनावश्यक रूप से अंतिम है, लेकिन आप इसे करने के लिए आपरेशन जोड़ना चाहते हैं:

class DecoratedStringBuffer { //extends StringBuffer doesn't work, as String is final 
    private String byContainmentThen; 
    public decorate(final String prefix, final String suffix) { ... } 
    public append(final String s) { byContainmentThen.append(s);} 
    // other forwarding functions 
} 

DecoratedStringBuffer के बाद से है-एक StringBuffer नहीं है, इससे पहले कि यह करने के लिए अपने कोड और रिटर्न छोड़ देता है क्लाइंट कोड, इसे संभवतः एक फ़ंक्शन द्वारा परिवर्तित किया जाना चाहिए, जो अंततः प्रत्यय और उपसर्ग को लागू करता है।यह बहुत अच्छा होगा अगर हम उस ऑपरेटर स्ट्रिंगबफर() को कॉल कर सकते हैं (और यदि जावा, सी ++ की तरह भी अधिक हो, तो उपयोगकर्ता द्वारा प्रदत्त रूपांतरण लागू हो सकता है)।

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

toStringBuffer() एक बेहतर नाम है, और पैटर्न जो मैं लागू करता हूं, लेकिन फिर कोड को पढ़ने वाले किसी को आश्चर्य होता है कि गेटटर की तरह दिखने के लिए क्लासनाम को "टू" कहा जाता है।

ईमानदारी से, संख्यात्मक कक्षाओं या "स्पष्ट रूप से" कोकेटेनेटेबल ऑब्जेक्ट्स को डिजाइन करने के अलावा, ओप + ओवरलोडिंग के लिए बहुत कम उपयोग है। और चूंकि जावा मूल्य-आधारित नहीं है जैसे सी ++, op = के लिए बहुत अधिक उपयोग नहीं है; जावा सब कुछ एक आदिम int मूल्य वर्ग की तरह कार्य करने की कोशिश नहीं कर रहा है। यह ओप() और रूपांतरण ऑपरेटर मुझे याद आती है।