गेटर्स और सेटर्स। क्या प्रदर्शन ओवरहेड है?

Question

मेरे पास मेरे सी ++ प्रोजेक्ट में एक कण प्रणाली इंजन है और कण स्वयं किसी भी कार्य के साथ चर के structs हैं। वर्तमान में, प्रत्येक कण (कण) को इसके चरम वर्ग (कण प्रणाली) से अद्यतन किया जाता है जिससे इसके चर सीधे पहुंचे जाते हैं। जैसे

particle.x += particle.vx; 

मैं हालांकि हूँ, इस तरह getters और setters का उपयोग कर बहस:

particle.setX(particle.getX()+particle.getVX());

मेरा प्रश्न है: सिर्फ सीधे डेटा का बैकअप करने के लिए विरोध के रूप में getters और setters कॉल करने से किसी भी प्रदर्शन भूमि के ऊपर है पहुंच?

सब के बाद, मैं के माध्यम से अद्यतन करने के लिए कई कई कणों की क्या ज़रूरत है ...

Answer 1

सेटर्स और गेटर्स का प्रदर्शन ओवरहेड है जब ऑप्टिमाइज़ नहीं किया गया है। वे लगभग हमेशा संकलक पर ऑप्टिमाइज़ किए जाते हैं जो लिंक समय अनुकूलन करते हैं। और उन कंपाइलरों पर जो नहीं करते हैं, अगर उन्हें फ़ंक्शन बॉडी (यानी न केवल प्रोटोटाइप) का ज्ञान है, तो इसे अनुकूलित किया जाएगा।

हालांकि, आप गेटर्स और सेटर्स का उपयोग करते हैं क्योंकि आप अतिरिक्त चर प्रभाव के लिए उस चर को प्राप्त या सेट करना चाहते हैं। किसी ऑब्जेक्ट की स्थिति बदलने की तरह भौतिकी सिमुलेशन या कुछ ऐसे में आस-पास की वस्तुओं की स्थिति भी बदलती है।

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

तो समेट करने के लिए, गेटर्स और सेटर्स नाबालिग या अस्तित्वहीन ओवरहेड के लायक हैं, क्योंकि यह आपको विशेष रूप से निर्दिष्ट करने की अनुमति देता है कि आपकी वस्तु के साथ क्या हो सकता है और नहीं हो सकता है, और यह आपको किसी भी बदलाव को मार्शल करने की अनुमति देता है।

Answer 2

getters और setters अगर हो रही है और स्थापित करने के लिए बाहर बारी थोड़ा और अधिक जटिल कार्य है, तो आपका कोड भविष्य में और अधिक आसानी से विकसित करने के लिए अनुमति देते हैं । अधिकांश सी ++ कंपाइलर्स inline के लिए पर्याप्त सरल तरीके हैं और फ़ंक्शन कॉल के ओवरहेड को खत्म करते हैं।

Answer 3

इस प्रश्न के कई जवाब हो सकते हैं, लेकिन मैंने अपने विचार यहां दिए।

प्रदर्शन के लिए, लागत को सामान्य पीओडी प्रकार के लिए अधिकतर अनदेखा किया जा सकता है। लेकिन अभी भी लागत है, और यह इस बात पर निर्भर करता है कि आप किस प्रकार लौटते हैं। कण के लिए, अधिक डेटा नहीं हो सका। यदि यह एक छवि वर्ग (जैसे ओपनसीवी सीवी :: मैट), या 3 डी डेटा (जैसे वीटीके में पॉलीडाटा) है, तो यह बेहतर है कि स्मृति आवंटन समस्या से बचने के लिए वास्तविक डेटा की तुलना में पॉटर/इटरेटर के साथ सेटर/गेटटर सौदों।

जब आप टेम्पलेट चीजों को देखना चाहते हैं, तो सेटर/गेटर निष्पक्ष प्रकार रूपांतरण से बचने के लिए बहुत उपयोगी हो सकता है। एक सेटर/गेटर निजी/संरक्षित सदस्य तक पहुंचने का एक तरीका हो सकता है, जो आपको x का उपयोग करने के लिए वैरिएबल के सामान्य नाम के रूप में भी बचने की अनुमति देता है। अधिक से अधिक, सेटर/गेटर एक लवल्यू संदर्भ लौटा सकता है जो आपको particle.getX() = 10.0 ;

Answer 4

मेरे पिछले जवाबों की तुलना में अलग राय देता है।

गेटर्स और सेटर्स संकेत हैं कि आपकी कक्षा को एक उपयोगी तरीके से डिज़ाइन नहीं किया गया है: यदि आप आंतरिक कार्यान्वयन से बाह्य व्यवहार सार नहीं बनाते हैं, तो पहले स्थान पर एक अमूर्त इंटरफ़ेस का उपयोग करने में कोई बात नहीं है, आप एक सादे पुरानी संरचना का भी उपयोग कर सकते हैं।

इस बारे में सोचें कि आप वास्तव में कौन से परिचालन की आवश्यकता है। यह लगभग निश्चित रूप से स्थिति और गति के x-y- और z-coordinates तक सीधे पहुंच नहीं है, बल्कि आप इन्हें वेक्टर मात्राओं के रूप में देखना चाहते हैं (कम से कम अधिकांश गणनाओं में, जो ऑप्टिमाइज़ेशन के लिए प्रासंगिक है)। तो आप एक वेक्टर-आधारित इंटरफ़ेस * को कार्यान्वित करना चाहते हैं, जहां मूल संचालन वेक्टर जोड़, स्केलिंग और आंतरिक उत्पाद होते हैं। घटक-वार पहुंच नहीं; आपको शायद कभी-कभी ऐसा करने की ज़रूरत होती है, लेकिन यह एक std::array<double,3> to_posarray() सदस्य या उसके जैसा कुछ भी किया जा सकता है।

जब आंतरिक घटक x, y ... vz बाहर से उपलब्ध नहीं हैं, तो आप अपने मॉड्यूल के बाहर किसी भी कोड को ब्रेक किए बिना आंतरिक कार्यान्वयन को सुरक्षित रूप से बदल सकते हैं। यह गेटर्स/सेटर्स से पूरी बात है; हालांकि इनका उपयोग करते समय केवल इतना ही अनुकूलन है कि आप कर सकते हैं: कार्यान्वयन के किसी भी वास्तविक परिवर्तन के साथ अनिवार्य रूप से गेटर्स को धीमा कर देते हैं।
दूसरी ओर, आप एक वेक्टर-आधारित इंटरफ़ेस से बाहर निकल सकते हैं, सिम ऑपरेशंस, बाहरी लाइब्रेरी कॉल (संभवतः सीयूडीए जैसे त्वरित हार्डवेयर पर) और इसी तरह। to_posarray जैसे "बैच-गेटर" को अभी भी उचित रूप से कार्यान्वित किया जा सकता है, सिंगल-वेरिएबल सेटर्स नहीं कर सकते हैं।

---

* मैं mathematical sense यहाँ में वेक्टर मतलब है, std::vector पसंद नहीं।