क्या सदस्य कार्य "कॉन्स्ट" होना चाहिए यदि वे तार्किक स्थिति को प्रभावित करते हैं, लेकिन बिटवाई स्थिति नहीं?

Question

मैं एक कक्षा लिख ​​रहा हूं जो एक विरासत सी एपीआई को लपेटता है जो हार्डवेयर डिवाइस को नियंत्रित करता है। एक सरलीकृत उदाहरण में, मेरे पास कुछ ऐसा हो सकता है:

class device 
{ 
public: 
    void set_request(int data) { legacy_set_req(p_device, data); } 
    int get_response() const { return legacy_get_rsp(p_device); } 
private: 
    device_handle_t *const p_device; 
}; 

कक्षा में कोई बिटवाई स्थिति नहीं है; इसलिए, मैं set_request() को const के रूप में घोषित करना चुन सकता हूं, और संकलक इससे खुश होंगे। हालांकि, एक अर्थपूर्ण दृष्टिकोण से, क्या यह सही दृष्टिकोण होगा, यह देखते हुए कि यह ऑब्जेक्ट के व्यवहार को प्रभावित करता है? (अर्थात समझाया हार्डवेयर डिवाइस बहुत ज्यादा करता राज्य है।)

Answer 1

मेरा मानना ​​है कि const आंतरिक प्रतिनिधित्व के बावजूद तार्किक कॉन्स्ट-नेस को प्रतिबिंबित करना चाहिए। सिर्फ इसलिए कि आपकी ऑब्जेक्ट में कुछ बदलाव करने वाले पॉइंटर होते हैं, इसका मतलब यह नहीं है कि आपके सभी सदस्य फ़ंक्शन const होना चाहिए।

सी ++ में भी mutable आंतरिक प्रतिनिधित्व के लिए अवधारणा है जिसे अवधारणात्मक रूप से ऑब्जेक्ट नहीं होने पर भी बदलने की आवश्यकता है। const कीवर्ड स्पष्ट रूप से "bitwise" कॉन्स्ट-नेस का प्रतिनिधित्व करने का इरादा नहीं है।

Answer 2

यह राज्य बदलता है, यह आम तौर पर नहींconst होना चाहिए। तथ्य यह है कि प्रश्न में राज्य दूरस्थ रूप से स्वामित्व में है (यानी, एक नियंत्रित डिवाइस में) उसमें बदलाव नहीं करता है।

Answer 3

अन्य प्रकार और सदस्य योग्यता (जैसे, सार्वजनिक, निजी, आभासी) की तरह, कॉन्स दोनों इरादे और भाषा अर्थशास्त्र (यानी सुरक्षा सुविधाओं) को व्यक्त करता है जो उस इरादे का समर्थन करते हैं। इस मामले में, इरादा काउंटर-अंतर्ज्ञानी दिखाई देगा, भले ही अंतर्निहित अर्थशास्त्र सुरक्षित रहे। मैं यह नहीं करूँगा।

Answer 4

एक उपयोगी परीक्षण है:

        डिवाइस उदाहरण के लिए एक ही const उपयोग के साथ कोड सकता है गैर const उपयोग के साथ कोड के संचालन

मूल रूप से के साथ हस्तक्षेप, const पहुँच होती है इसका मतलब है कि आप प्रभावी रूप से पर्यवेक्षक हैं। यहां, ऐसा लगता है कि कोड set_request(...) समय पर टी 1 पर get_response() समय पर टी 3 गंभीर रूप से खराब हो जाएगा यदि कुछ अनुमानित पर्यवेक्षक set_request() को समय-समय पर विभिन्न पैरामीटर के साथ बुलाते हैं। इसी कारण से, set_request(...) पर्यवेक्षकों के लिए सुलभ नहीं होना चाहिए - यह गैर-const होना चाहिए।

(परीक्षण के लिए चेतावनियां हैं - जैसे अगर एक const "पर्यवेक्षक" एक ताला की जरूरत है यह स्पष्ट रूप से एक समय के नजरिए से एक और धागे से गैर const उपयोग को प्रभावित कर सकते हैं, लेकिन एक कार्यात्मक एक से ऐसा नहीं करना चाहिए - जो कि बहुत स्पष्ट है कि आपके विश्लेषण में कारक कैसे करें)।