सी कार्यक्रमों में दो विरोधाभास

मैं दो विषमताओं के बारे में बात करना चाहता हूं, जो मुझे सी में कम्प्यूटेशनल एल्गोरिदम की प्रोग्रामिंग करते समय सामना करना पड़ा था

तो, कुछ प्रोग्रामर के लिए पहला अप्रत्याशित व्यवहार। यहाँ एक छोटा सा कार्यक्रम है।

#include <stdio.h> int main() { unsigned char a = 1, b; b = ~a >> 1; printf("%u\n", b); return 0; } 

आइए इसका विश्लेषण करते हैं। बिटवाइज़ ऑपरेशन ~ प्रत्येक बिट ऑफ़ द स्टेट को बाइट करता है a , जिसमें यूनिट मूल रूप से लिखा गया था। परिणाम 11111110b , यानी 254 होना चाहिए। इस बाइट को दाईं ओर एक बिट में स्थानांतरित करने पर 127 प्राप्त करना चाहिए। हालाँकि, दिए गए कोड, उदाहरण के लिए, gcc संकलक द्वारा, कंसोल के लिए 255 आउटपुट है ?!

पहले तो मैंने सोचा कि मामला प्राथमिकता का है - क्या होगा यदि कंपाइलर के संचालन की प्राथमिकता "मॉव" है? यही है, जैसे कि पहली बार एक बदलाव किया जाता है, और फिर - उलटा (और यह तर्कसंगत है ...)। तो सौदा क्या है?

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

इसकी पुष्टि निम्नलिखित कोड द्वारा की जाती है।

 #include <stdio.h> int main() { unsigned char a = 1, b; b = (unsigned char)~a >> 1; printf("%u\n", b); return 0; } 

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

 mov [ebp+var_6], 1 movzx eax, [ebp+var_6] not eax sar eax, 1 mov [ebp+var_5], al 

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

जैसा कि बाद में पता चला, इस स्थिति को इंटेगर प्रमोशन कहा जाता है और इसे C99 मानक के खंड 6.3.1.1 में वर्णित किया गया है । आप इसे यहाँ से डाउनलोड कर सकते हैं www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf

कुछ प्रोग्रामर के लिए दूसरा अप्रत्याशित व्यवहार वास्तविक संख्याओं के साथ है। हमारे पास निम्नलिखित कोड है।

 #include <stdio.h> int main() { float a = 1.005, b = 1000; int c = a*b; printf("%d\n", c); return 0; } 

इसे 4.1.1 gcc के साथ संकलित करने पर , मुझे 1004 मिलते हैं। फिर सवाल - अजीब परिणाम कहाँ से आता है? यहां तक ​​कि

 int c = (float)(a*b); 

भी सही परिणाम नहीं देता है।

C89 मानक के अनुसार चढ़ते हुए, यह पता चला कि उसने वास्तविक संख्याओं के साथ काम करने के तरीकों के बारे में कुछ भी विनियमित नहीं किया है। आखिरकार, जब एसएसई विस्तार दिखाई दिया, तो कंपाइलरों ने मिश्रित तरीके से गणना करना शुरू कर दिया - क्योंकि यह तेजी से गिना जाता है: एफपीयू पर कुछ, एसएसई पर कुछ। नए C99 मानक में कुछ निश्चितता है। कंपाइलर को उस मान के लिए मैक्रो मान FLT_EVAL_METHOD (शीर्ष लेख फ़ाइल float.h ) को 0 , 1 , 2 पर सेट करना चाहिए। तो, 0 - सब कुछ गिना जाता है जैसा कि लिखा गया है; 1 - फ्लोट वास्तव में डबल में गिना जाता है और फिर वापस फ्लोट में परिवर्तित होता है; 2 - क्रमशः गणना के अंत में फ्लोट या डबल में कनवर्ट करते हुए सब कुछ लंबे डबल में गिनें।

अब, प्रोग्राम को गिनती के रूप में इसे करना चाहिए, आपको इसे इकट्ठा करने की आवश्यकता है

 gcc proga.c -msse 

उसके बाद ही मुझे कंसोल में 1005 मिले। यह पता चला कि gcc संकलक का मेरा संस्करण मैक्रो FLT_EVAL_METHOD का समर्थन नहीं करता है। वैसे, डबल जीसीसी के साथ एक कोड आउटपुट 1004 देता है। केवल इंटेल सी 9.0 ने दोहरे के साथ सामान्य कोड बनाया, लेकिन जब मैंने लिखा

 int c = (float)(a*b); 

(यहां ए और बी पहले से ही टाइप डबल हैं )। टाइप कास्टिंग के बिना, वहाँ कोड भी 1004 देता है।