🤳🏼 📱 🤹🏿 सी ++ 11 और 64-बिट त्रुटियां 👲🏾 👨🏿‍🤝‍👨🏾 🏕️

हमने स्थैतिक कोड विश्लेषण के विषय को विराम देने का निर्णय लिया। आखिरकार, C ++ ब्लॉग उन लोगों द्वारा भी पढ़ा जाता है जिन्होंने अभी तक इस तकनीक का उपयोग नहीं किया है। इस बीच, C ++ दुनिया में घटनाएं हो रही हैं जो 64-बिट दुनिया के रूप में इस तरह के "अच्छी तरह से स्थापित" विषय को प्रभावित करती हैं। यह सही 64-बिट प्रोग्राम के विकास में C ++ 11 मानक कैसे प्रभावित करता है और इसमें मदद करता है (यदि कुछ है तो) इसके बारे में है। आज का लेख बस इतना ही।

64-बिट कंप्यूटर का उपयोग लंबे समय से सफलतापूर्वक किया गया है। अधिकांश एप्लिकेशन 64-बिट बन गए हैं। यह उन्हें अधिक मेमोरी का उपयोग करने की अनुमति देता है, साथ ही 64-बिट प्रोसेसर की वास्तु क्षमताओं के कारण प्रदर्शन को बढ़ावा मिलता है। 64-बिट C / C ++ प्रोग्राम बनाने के लिए प्रोग्रामर से ध्यान हटाने की आवश्यकता होती है। ऐसे कई कारण हैं जिनकी वजह से एक 32-बिट प्रोग्राम का कोड 64-बिट सिस्टम के लिए पुनर्मूल्यांकन के बाद सही तरीके से काम करने से इनकार करता है। इस बारे में कई लेख लिखे गए हैं। लेकिन अब हम एक और सवाल में रुचि रखते हैं। आइए देखें कि क्या C ++ 11 में शुरू की गई नई सुविधाओं का उपयोग करने से प्रोग्रामर के लिए 64-बिट प्रोग्राम बनाने में जीवन आसान हो जाता है।

64-बिट त्रुटियों की दुनिया

कई जाल हैं जो एक प्रोग्रामर 64-बिट सी / सी ++ एप्लिकेशन बनाते समय गिर सकते हैं। इस बारे में बड़ी संख्या में लेख लिखे गए हैं, इसलिए हम इसे नहीं दोहराएंगे। निम्नलिखित संसाधन उन लोगों के लिए सुझाए जा सकते हैं जो 64-बिट कार्यक्रमों को विकसित करने की बारीकियों से परिचित नहीं हैं या वे जो अपने जीवन को ताज़ा करना चाहते हैं:

समय अभी भी खड़ा नहीं है, और अब प्रोग्रामर सी ++ भाषा के एक अद्यतन संस्करण का उपयोग कर रहे हैं, जिसे सी ++ 11 कहा जाता है। फिलहाल, C ++ 11 भाषा मानक में वर्णित अधिकांश नवाचार आधुनिक संकलक द्वारा समर्थित हैं। आइए देखें कि क्या ये नवाचार किसी तरह से प्रोग्रामर को 64-बिट त्रुटियों से बचने में मदद कर सकते हैं।

लेख का निर्माण निम्नानुसार किया जाएगा। 64-बिट त्रुटि का एक संक्षिप्त विवरण दिया जाएगा, और C ++ 11 का उपयोग करने से बचने के तरीके सुझाए जाएंगे। तुरंत, हम ध्यान दें कि हमेशा C ++ 11 से कम से कम मदद मिल सकती है। केवल त्रुटि-मुक्त प्रोग्रामिंग त्रुटियों से रक्षा कर सकती है। और नया मानक केवल इसमें मदद करता है, लेकिन प्रोग्रामर के लिए सभी समस्याओं का समाधान नहीं करता है।

मैजिक नंबर

यह 4, 32, 0x7FFFFFFF, 0xFFFFFFFF ( अधिक ) जैसे नंबरों का उपयोग करने के बारे में है। यह बुरा है अगर प्रोग्रामर ने मान लिया कि सूचक का आकार हमेशा 4 बाइट्स होता है और यह कोड लिखा होता है:

int **array = (int **)malloc(n * 4);

यहाँ, C ++ 11 मानक हमारी मदद नहीं कर सकता है। मैजिक नंबर खराब हैं और गलतियों से बचने का एकमात्र तरीका है कि उनका इस्तेमाल न करने की कोशिश की जाए।

नोट। हां, मॉलोक () C ++ नहीं है, लेकिन अच्छा पुराना C. यह नए ऑपरेटर या std :: वेक्टर कंटेनर का उपयोग करने के लिए बेहतर है। लेकिन अब यह अप्रासंगिक है। जादू की संख्या के बारे में बात करें।

हालांकि, C ++ 11 कभी-कभी जादू की संख्या को कम करने में मदद करता है। कार्यक्रम में कुछ मैजिक नंबर डर (अक्सर अनुचित) के कारण दिखाई देते हैं कि कंपाइलर कोड को अच्छी तरह से अनुकूलित नहीं करता है। इस मामले में, यह सामान्यीकृत स्थिर अभिव्यक्तियों (बाधा) पर ध्यान देने योग्य है।

कॉन्स्ट्रेक्स तंत्र यह सुनिश्चित करता है कि संकलित संकलन समय पर अभिव्यक्त किए जाएं। उसी समय, आप उन कार्यों की घोषणा कर सकते हैं जो संकलन चरण में एक स्थिर पर तैनात करने की गारंटी है। एक उदाहरण:

 constexpr int Formula(int a) { constexpr int tmp = a * 2; return tmp + 55; } int n = Formula(1);

फॉर्मूला (1) फ़ंक्शन के लिए एक कॉल एक संख्या में बदल जाएगी। स्पष्टीकरण बहुत छोटा है। आप लेख के अंत में लिंक पर क्लिक करके "कॉन्स्टैक्स" और अन्य नवाचारों के बारे में अधिक पढ़ सकते हैं।

विभिन्न प्रकार के तर्क के साथ कार्य

हम प्रिंटफ, स्कैनफ ( अधिक ) जैसे कार्यों के दुरुपयोग के बारे में बात कर रहे हैं। एक उदाहरण:

 size_t value = ....; printf("%u", value);

यह कोड 32-बिट प्रोग्राम में सही तरीके से काम करता है, लेकिन जब प्रोग्राम 64-बिट में बदल जाता है तो गलत मान प्रिंट कर सकता है।

एक चर संख्या के साथ कार्य C भाषा के अवशेष हैं। उनका नुकसान वास्तविक तर्कों के प्रकारों पर नियंत्रण की कमी है। C ++ में, उन्हें छोड़ने का समय है। तार को प्रारूपित करने के अन्य तरीके हैं। उदाहरण के लिए, आप प्रिंटफ़ को कॉउट से बदल सकते हैं, और स्प्रिंटफ़ को बढ़ावा देने के साथ :: प्रारूप या std :: stringstream।

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

 void printf(const char* s) { while (s && *s) { if (*s=='%' && *++s!='%') throw runtime_error("invalid format: missing arguments"); std::cout << *s++; } } template<typename T, typename... Args> void printf(const char* s, T value, Args... args) { while (s && *s) { if (*s=='%' && *++s!='%') { std::cout << value; return printf(++s, args...); } std::cout << *s++; } }

यह कोड केवल पहला तर्क "बाहर खींचता है", जो एक प्रारूप स्ट्रिंग नहीं है, और फिर खुद को पुनरावर्ती कहता है। जब इस तरह के तर्क नहीं होते हैं, तो प्रिंटफ () पद्धति का पहला (सरल) संस्करण कहा जाएगा।

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

 printf(++s, args...);

आर्ग्स पैरामीटर समूह को एक के द्वारा स्थानांतरित किया जाता है, और अगले पैरामीटर को मूल्य के रूप में संसाधित किया जा सकता है। और यह तब तक जारी रहता है जब तक कि आर्गन्स खाली नहीं हो जाता है (और प्रिंटफ़ () विधि का पहला संस्करण कहा जाता है)।

गलत पारी संचालन

संख्यात्मक शाब्दिक 1 प्रकार int का है। इसका मतलब है कि इसे 31 से अधिक बिट्स ( अधिक ) द्वारा स्थानांतरित नहीं किया जा सकता है। यह अक्सर भूल जाता है, और कार्यक्रमों में आप इस कोड को पा सकते हैं:

 ptrdiff_t mask = 1 << bitNum;

यदि बिटनेम मान 40 के बराबर है, तो परिणाम अप्रत्याशित होगा। औपचारिक रूप से, यह अपरिभाषित व्यवहार ( अधिक ) को जन्म देगा।

C ++ 11 हमारी मदद कर सकता है? दुर्भाग्य से, कुछ भी नहीं।

वर्चुअल फ़ंक्शन desync

बेस क्लास में वर्चुअल फंक्शन घोषित किया जाए:

 int A(DWORD_PTR x);

और उत्तराधिकारी वर्ग में एक कार्य है:

 int A(DWORD x);

32-बिट प्रोग्राम में, DWORD_PTR और DWORD के प्रकार समान हैं। हालांकि, 64-बिट प्रोग्राम में, ये पहले से ही दो अलग-अलग प्रकार ( अधिक ) हैं। नतीजतन, बेस क्लास से फ़ंक्शन ए को 32-बिट और 64-बिट प्रोग्राम में अलग-अलग परिणाम मिलेंगे।

ऐसी त्रुटियों से निपटने के लिए, C ++ 11 में दिखाई देने वाले नए कीवर्ड मदद कर सकते हैं।

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

यह कोड 64-बिट मोड में संकलित नहीं होगा और इस तरह त्रुटि को बेअसर कर दिया जाएगा:

 struct X { virtual int A(DWORD_PTR) { return 1; } }; struct Y : public X { int A(DWORD x) override { return 2; } };

मिश्रित अंकगणित

यह एक काफी महत्वपूर्ण और व्यापक विषय है। मैं "64-बिट सबक" के संबंधित बैकलॉग से परिचित होने का प्रस्ताव करता हूं: मिश्रित अंकगणित ।

बहुत संक्षेप में:

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

आइए कुछ सरल अतिप्रवाह उदाहरण देखें।

 char *p = new char[1024*1024*1024*5];

प्रोग्रामर स्मृति के 5 गीगाबाइट की एक सरणी आवंटित करने की कोशिश कर रहा है, लेकिन बहुत कम आवंटित करेगा। तथ्य यह है कि अभिव्यक्ति "1024 * 1024 * 1024 * 5" प्रकार का है। नतीजतन, एक अतिप्रवाह होगा, और अभिव्यक्ति 1073741824 (1 गीगाबाइट) होगी। फिर, 'नए' संचालक के पास जाने पर, संख्या 1073741824 का आकार type_t तक विस्तारित किया जाएगा, लेकिन इससे कोई फर्क नहीं पड़ता (यह बहुत देर हो चुकी है)।

यदि समस्या स्पष्ट नहीं है, तो यहाँ एक और समान उदाहरण है:

 unsigned a = 1024, b = 1024, c = 1024, d = 5; size_t n = a * b * c * d;

अभिव्यक्ति का परिणाम टाइप 'size_t' के एक चर में रखा गया है। यह UINT_MAX से अधिक मूल्यों को संग्रहीत करने में सक्षम है। लेकिन जब 'अहस्ताक्षरित' प्रकार के चर को बढ़ाते हैं, तो एक अतिप्रवाह होता है और परिणाम गलत होगा।

हम यह सब 64-बिट त्रुटियों को क्यों कहते हैं? तथ्य यह है कि 32-बिट प्रोग्राम में 2 गीगाबाइट से बड़े सरणी को आवंटित करना असंभव है। इसलिए, ओवरफ्लो बस उत्पन्न नहीं होता है। ऐसी त्रुटियां केवल 64-बिट कार्यक्रमों में ही प्रकट होती हैं, जब वे बड़ी मात्रा में मेमोरी के साथ काम करना शुरू करते हैं।

अब तुलना के बारे में कुछ उदाहरण

 size_t Count = BigValue; for (unsigned Index = 0; Index < Count; ++Index) { ... }

यह एक स्थायी लूप का एक उदाहरण है यदि गणना> UINT_MAX। मान लीजिए कि 32-बिट सिस्टम पर इस कोड को पुनरावृत्ति से कम, UINT_MAX बार से कम निष्पादित किया गया है। लेकिन कार्यक्रम का 64-बिट संस्करण अधिक डेटा संसाधित कर सकता है, और इसके लिए अधिक पुनरावृत्तियों की आवश्यकता हो सकती है। चूंकि सूचकांक चर का मान सीमा [0..UINT_MAX] में निहित है, इसलिए "इंडेक्स <गणना" स्थिति हमेशा संतुष्ट रहती है, जो एक अनंत लूप की ओर ले जाती है।

एक और उदाहरण:

 string str = .....; unsigned n = str.find("ABC"); if (n != string::npos)

यह कोड गलत है। फ़ंक्शन () फ़ंक्शन टाइप स्ट्रिंग का एक मान देता है :: size_type। 32-बिट सिस्टम पर सब कुछ ठीक काम करेगा। लेकिन देखते हैं कि 64-बिट प्रोग्राम में क्या होता है।

64-बिट प्रोग्राम में, स्ट्रिंग :: size_type और अहस्ताक्षरित cease मिलान के लिए। यदि सबस्ट्रिंग नहीं मिला है, तो खोज () फ़ंक्शन स्ट्रिंग का मान देता है :: npos, जो 0xFFFFFFFFFFFFFFFFFFui64 है। यह मान 0xFFFFFFFFu से छोटा है और 32-बिट चर में रखा गया है। अभिव्यक्ति की गणना की गई है: 0xFFFFFFFFFF! = 0xFFFFFFFFFFFFFFFFFFFFui64 यह पता चला है कि स्थिति (n! = स्ट्रिंग :: npos) हमेशा सही होती है!

क्या C ++ 11 किसी तरह यहां मदद कर सकता है?

इसका उत्तर हां और नहीं है।

कुछ मामलों में, नया ऑटो कीवर्ड हमारी मदद कर सकता है। और कुछ में, यह केवल प्रोग्रामर को भ्रमित कर सकता है। इसलिए, आइए ध्यान से समझें।

यदि आप "ऑटो ए = ....." घोषित करते हैं, तो इसके प्रकार की गणना स्वचालित रूप से की जाएगी। यह बहुत महत्वपूर्ण है कि भ्रमित न हों और ऐसा गलत कोड न लिखें: "ऑटो एन = 1024 * 1024 * 1024 * 5"।

ऑटो कीवर्ड के बारे में बात करें। निम्नलिखित उदाहरण पर विचार करें:

 auto x = 7;

इस स्थिति में, वेरिएबल 'x' का प्रकार 'int' होगा, क्योंकि यह ठीक उसी प्रकार का है जैसा कि इसके इनिशलाइज़र का है। सामान्य तौर पर, हम लिख सकते हैं:

 auto x = expression;

और चर 'x ’का प्रकार अभिव्यक्ति का मूल्यांकन करके प्राप्त मूल्य के प्रकार के बराबर होगा।

अपने इनिशियलाइज़र से एक वैरिएबल के प्रकार को आउटपुट करने के लिए कीवर्ड 'ऑटो' सबसे उपयोगी होता है जब सटीक प्रकार की अभिव्यक्ति ज्ञात नहीं होती है या लिखना मुश्किल होता है। एक उदाहरण पर विचार करें:

 template<class T> void printall(const vector<T>& v) { for (auto p = v.begin(); p!=v.end(); ++p) cout << *p << "\n"; }

C ++ 98 में, आपको बहुत लंबा कोड लिखना होगा:

 template<class T> void printall(const vector<T>& v) { for (typename vector<T>::const_iterator p = v.begin(); p!=v.end(); ++p) cout << *p << "\n"; }

C ++ 11 में एक बहुत ही उपयोगी नवाचार।

आइए हम अपनी समस्या पर वापस आते हैं। "1024 * 1024 * 1024 * 5" की अभिव्यक्ति प्रकार 'int' की है। तो अब के लिए, 'ऑटो' हमारी मदद नहीं करेगा।

लूप के मामले में 'ऑटो' हमारी मदद नहीं करेगा:

 size_t Count = BigValue; for (auto Index = 0; Index < Count; ++Index)

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

तो क्या 'ऑटो' से हमारे लिए कुछ अच्छा है? हाँ है। उदाहरण के लिए, यहां:

 string str = .....; auto n = str.find("ABC"); if (n != string::npos)

चर 'n' प्रकार स्ट्रिंग का होगा :: size_type। अब सब ठीक है।

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

वैसे, पहले से चर्चा किए गए उदाहरण में टाइप ट्रिमिंग से बचाने का एक और तरीका है:

 unsigned n = str.find("ABC");

आप नए चर आरंभीकरण प्रारूप का उपयोग कर सकते हैं, जो प्रकारों को संकीर्ण होने से रोकता है। समस्या यह है कि C और C ++ भाषाएं कुछ प्रकारों को विभाजित करती हैं:

 int x = 7.3; // ! void f(int); f(7.3); // !

हालाँकि, C ++ 11 आरंभीकरण सूचियाँ प्रकारों के संकुचन की अनुमति नहीं देती हैं:

 int x0 {7.3}; //compilation error int x1 = {7.3}; //compilation error double d = 7; int x2{d}; //compilation error

ये उदाहरण हमारे लिए अब और दिलचस्प हैं:

 size_t A = 1; unsigned X = A; unsigned Y(A); unsigned Q = { A }; //compilation error unsigned W { A }; //compilation error

कल्पना कीजिए कि कोड इस तरह लिखा गया है:

 unsigned n = { str.find("ABC") };   unsigned n{str.find("ABC")};

यह कोड 32-बिट मोड में संकलित होगा और 64-बिट मोड में संकलन बंद कर देगा।

फिर, यह सभी गलतियों के लिए रामबाण नहीं है। अधिक विश्वसनीय कार्यक्रम लिखने के लिए बस एक और तरीका।

पता अंकगणित

समस्या काफी हद तक "मिश्रित अंकगणित" अनुभाग में जांच की गई समान है। एकमात्र अंतर यह है कि पॉइंटर्स ( अधिक ) के साथ काम करने पर अतिप्रवाह होता है।

एक उदाहरण पर विचार करें:

 float Region::GetCell(int x, int y, int z) const { return array[x + y * Width + z * Width * Height]; }

यह कोड एक वास्तविक गणितीय मॉडलिंग कार्यक्रम से लिया गया है जिसमें RAM की मात्रा एक महत्वपूर्ण संसाधन है। इस वर्ग के कार्यक्रमों में, स्मृति को बचाने के लिए एक-आयामी सरणियों का उपयोग अक्सर किया जाता है, उनके साथ त्रि-आयामी सरणियों के रूप में काम करना। ऐसा करने के लिए, गेटसेल के समान कार्य हैं जो आवश्यक तत्वों तक पहुंच प्रदान करते हैं। लेकिन उपरोक्त कोड केवल INT_MAX तत्वों से कम वाले सरणियों के साथ सही ढंग से काम करेगा। कारण तत्व के सूचकांक की गणना करने के लिए 32-बिट इंट प्रकार का उपयोग है।

क्या C ++ 11 किसी तरह यहां मदद कर सकता है? नहीं।

सरणी प्रकार और पैकेजिंग पॉइंटर्स बदलें।

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

गलत परिणाम देने से गलत गलतियाँ होती हैं। नए C ++ 11 मानक के साथ कोई संबंध नहीं है। स्पष्ट कास्ट हमेशा आपके जोखिम और जोखिम पर किया जाता था।

संघों में डेटा के साथ काम करने के बारे में भी उल्लेख किया जाना चाहिए। डेटा के साथ ऐसा काम निम्न स्तर का है और यह केवल प्रोग्रामर के कौशल और ज्ञान ( अधिक ) पर निर्भर करता है।

सरलीकरण और डेटा विनिमय

एक प्रोजेक्ट को एक संगत डेटा प्रारूप बनाने की आवश्यकता हो सकती है। यही है, एक डेटा सेट को प्रोग्राम के 32-बिट और 64-बिट संस्करण दोनों द्वारा संसाधित किया जाना चाहिए। कठिनाई इस तथ्य में निहित है कि कुछ प्रकार के डेटा के आकार बदल रहे हैं ( अधिक )।

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

अब निश्चित आकार के निम्न प्रकार हैं:

int8_t
int16_t
int32_t
int64_t
uint8_t
uint16_t
uint32_t
uint64_t

आकार के अलावा, मेमोरी में डेटा के संरेखण को बदल दिया जाता है। यह भी कुछ कठिनाइयों ( अधिक ) प्रदान कर सकता है।

इस विषय के संबंध में, यह नए कीवर्ड 'संरेखण' के C ++ 11 में उपस्थिति का उल्लेख करने योग्य है। अब आप इस कोड को लिख सकते हैं:

 //  ,     double alignas(double) unsigned char c[1024]; //   16   alignas(16) char[100];

एक 'संरेखित' कथन भी है जो निर्दिष्ट तर्क के लिए संरेखण लौटाता है (तर्क एक प्रकार होना चाहिए)। एक उदाहरण:

 constexpr int n = alignof(int);

अतिभारित कार्य

32-बिट प्रोग्राम को 64-बिट प्लेटफॉर्म पर पोर्ट करते समय, ओवरलोड कार्यों के उपयोग से जुड़े इसके संचालन के तर्क में बदलाव हो सकता है। यदि फ़ंक्शन 32-बिट और 64-बिट मानों के लिए अवरुद्ध है, तो इसे एक तर्क के साथ एक्सेस करना, उदाहरण के लिए, type size_t का विभिन्न प्रणालियों ( अधिक ) पर विभिन्न कॉल में अनुवाद किया जाएगा।

मुझे यह जवाब देना मुश्किल है कि क्या ऐसी त्रुटियों का मुकाबला करने के लिए भाषा के नए गुणों में से एक का उपयोग किया जा सकता है।

टाइप साइज चेक

ऐसे समय होते हैं जब डेटा प्रकारों के आकारों की जांच करना आवश्यक होता है। यह आवश्यक है ताकि नई प्रणाली के लिए कोड को फिर से जमा करने के बाद एक छोटी गाड़ी कार्यक्रम न हो।

यह अक्सर गलत तरीके से किया जाता है। उदाहरण के लिए, इस तरह:

 assert(sizeof(unsigned) < sizeof(size_t)); assert(sizeof(short) == 2);

बुरा तरीका। सबसे पहले, कार्यक्रम वैसे भी संकलित करता है। दूसरे, ये चेक केवल डिबग संस्करण में काम करेंगे।

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

 _STATIC_ASSERT(sizeof(int) == sizeof(long));

C ++ 11 ने कुछ गलत होने पर संकलन को रोकने के तरीके को मानकीकृत किया। भाषा में स्थैतिक दावे पेश किए गए हैं।

स्टेटिक स्टेटमेंट (संकलन-समय कथन) में एक स्थिर अभिव्यक्ति और एक स्ट्रिंग शाब्दिक होता है:

 static_assert(expression, string);

संकलक अभिव्यक्ति का मूल्यांकन करता है, और यदि गणना का परिणाम गलत है (यानी कथन का उल्लंघन किया गया है), तो यह त्रुटि संदेश के रूप में एक स्ट्रिंग प्रदर्शित करता है। उदाहरण:

 static_assert(sizeof(long)>=8, "64-bit code generation required for this library."); struct S { X m1; Y m2; }; static_assert(sizeof(S)==sizeof(X)+sizeof(Y), "unexpected padding in S");

निष्कर्ष

नए C ++ 11 निर्माण के अधिकतम उपयोग के साथ कोड लिखना 64-बिट त्रुटियों की अनुपस्थिति की गारंटी नहीं देता है। हालाँकि, भाषा कई नई सुविधाएँ प्रस्तुत करती है जो कोड को छोटा और अधिक विश्वसनीय बनाएगी।

अतिरिक्त संसाधन

लेख ने C ++ 11 भाषा में अधिक से अधिक नवाचारों के साथ पाठक को परिचित कराने का प्रयास नहीं किया। नए मानकों के साथ पहले परिचित के लिए, आप निम्नलिखित संसाधनों की सिफारिश कर सकते हैं:

बजरने स्ट्रॉस्ट्रुप। सी ++ 11 - नया आईएसओ सी ++ मानक ( महान अनुवाद )।
विकिपीडिया। C ++ 11 ।
स्कॉट मेयर्स। एक प्रभावी सी ++ 11/14 नमूना ।

सी ++ 11 और 64-बिट त्रुटियां