2009-06-04 5 views
51

मैं निम्नलिखित मामले के बारे में पूछना चाहता था:क्या मुझे स्पष्ट रूप से malloc() के वापसी मूल्य कास्ट करना चाहिए?

char *temp; 
temp = malloc(10); 

चूंकि malloc का रिटर्न प्रकार void* है, क्या malloc द्वारा लौटाए गए पॉइंटर को temp को असाइन किए जाने से पहले char* प्रकार पर डाला जाएगा? इस संबंध में मानक क्या कहता है?

यदि हमारे सूचक परिवर्तक उदाहरण के लिए कुछ संरचना प्रकार हैं:

struct node *temp; 
temp = (struct node *)malloc(sizeof(struct node)); 

अगर हम इसे struct node* प्रकार के बिना कास्ट किए बिना अस्थायी रूप से स्मृति आवंटित करते हैं, तो इसे स्पष्ट रूप से struct node* प्रकार में डाला जाएगा या यह स्पष्ट रूप से डालना आवश्यक है यह struct node* प्रकार के लिए?

+7

यदि आपको कभी भी सी कंपाइलर के बजाय सी ++ कंपाइलर के साथ कोड को संकलित करने की आवश्यकता हो, तो कलाकारों की आवश्यकता होती है। नतीजतन, मेरे अधिकांश कोड में स्पष्ट कास्ट शामिल है - भले ही शुद्ध सी को इसकी आवश्यकता नहीं है। मैं आमतौर पर इसे इंगित करने के लिए/* = सी ++ = */के साथ टैग करता हूं। –

+0

हालांकि जरूरी नहीं है, मेरे लिए मुझे थोड़ी सी वर्बसिटी के साथ बाद में कोड पढ़ने में मदद करता है। – Xolve

+2

यह भी देखें [यह प्रश्न] (http://stackoverflow.com/questions/605845/do-i-cast-the-result-of-malloc/605858#605858)। – unwind

उत्तर

33

सी में एक शून्य पॉइंटर किसी भी सूचक को स्पष्ट कलाकार के बिना असाइन किया जा सकता है।

+9

मुझे नहीं लगता कि यह फ़ंक्शन पॉइंटर्स पर लागू होता है। –

+11

सी इसे अपरिभाषित करता है चाहे आप फंक्शन पॉइंटर्स को गैर-फ़ंक्शन पॉइंटर्स या बैक पर डालें। सी ++ स्पष्ट रूप से इसे रोकता है, और सी ++ 1x सशर्त रूप से इसका समर्थन करता है –

+10

और पॉज़िक्स (कम से कम 2008) की आवश्यकता है कि फ़ंक्शन पॉइंटर्स डेटा पॉइंटर्स के समान आकार के हों, जहां सी मानक छोड़ देता है जो अनिर्धारित है। –

10

सी स्पष्ट रूप से void* से रहता है, इसलिए कास्ट स्वचालित रूप से किया जाएगा। सी ++ में केवल रूपांतरण सेvoid* निस्संदेह किया जाएगा, दूसरी दिशा के लिए एक स्पष्ट कलाकार की आवश्यकता है।

+2

नोट सी ++ बिना किसी कलाकार के एक शून्य * में रूपांतरण का समर्थन करता है। –

3

सी ++ में आपको स्पष्ट रूप से डालना होगा, लेकिन यह वास्तव में केवल भाषा है जो आपको यह करने के लिए कह रही है।
सी में वास्तव में डालने की कोई ज़रूरत नहीं है, स्मृति केवल स्मृति है - मुझे यह देखने के लिए एक खोज करना होगा कि नवीनतम सी मानक को इसकी आवश्यकता है या नहीं।

+2

सी 99 मानक को कास्ट की आवश्यकता नहीं है। –

49

यदि आपको "खुद को दोहराएं" मानसिकता पसंद नहीं है, तो यह आकर्षक होना चाहिए कि आपको malloc() कॉल में चर के घोषणापत्र से टाइप नाम दोहराने की आवश्यकता नहीं है। क्योंकि, जैसे लोगों ने इंगित किया है, आप नहीं करते हैं: पॉइंटर्स फ़ंक्शन पॉइंटर्स के अपवाद के साथ void * से बिना हानि के रूपांतरित होते हैं।

इसके अलावा, उस नोट पर, आपको sizeof के उपयोग से स्वयं को दोहराने की आवश्यकता नहीं है। आपकी दूसरी उदाहरण है, जब एक संरचना का आवंटन, इस तरह लिखा जा सकता है:

struct node *temp; 
temp = malloc(sizeof *temp); 

कौन सा मेरे इतने विनम्र राय में नहीं सबसे अच्छा तरीका है।

अपने आप को लिखने वाली चीजों की संख्या पर कटौती करने से बचें, जो बदले में जोखिम में कटौती करता है कि इनमें से कोई भी चीज़ गलत है।

sizeof तर्क में तारांकन पर ध्यान दें, इसका अर्थ यह है कि "इस सूचक द्वारा इंगित ऑब्जेक्ट का आकार", जो कि "struct node प्रकार का आकार" जैसा है, लेकिन प्रकार का नाम दोहराए बिना। ऐसा इसलिए है क्योंकि sizeof अभिव्यक्ति का आकार (संकलन-समय पर) गणना करता है जो इसकी तर्क है। इस मामले के लिए। sizeof 3 की तरहकी अभिव्यक्ति के आकार की गणना करता है, sizeof *tempstruct node के उदाहरण के आकार की गणना करता है।

ज़रूर, आप कुछ, अर्थात चर नाम ही दोहराने करते हैं, लेकिन है कि संकलक में एक त्रुटि को पहचानना आसान हो सकता है सही पाने के लिए अक्सर एक सरल अभिव्यक्ति और आसान है, और यह भी।

+6

+1 आकार * temp – diapir

+3

यह एक उदाहरण है जहां डीआरवाई लागू करना एक असुरक्षित प्रोग्रामिंग अभ्यास है (निम्न लिंक देखें)। पुनरावृत्ति से बचने वाला तर्क त्रुटियों को कम करता है प्रासंगिक है। जब सी में पॉइंटर्स की बात आती है, तो अस्पष्टता के लिए कुख्यात, इससे बुजुजू का कारण बन जाएगा। मैं वर्बोज़ बनता हूं और संकलन समय में समस्याओं को खोजने के लिए जानवरों को दोहराता हूं (रन-टाइम के विपरीत): https://www.securecoding.cert.org/confluence/display/seccode/MEM02-C.+Imedimedi+cast+ + + + + + + स्मृति + आवंटन + फ़ंक्शन + कॉल + + + + सूचक + + + आवंटित + प्रकार –

+3

सामान्य रूप से, safecoding.cert.org बकवास से भरा है। या, अधिक विनम्रतापूर्वक रखें, उस साइट पर मैंने जो भी लेख पढ़ा है, वह गलत जानकारी से भरा है ('ftell' बनाम' fstat') के बारे में सोचें, शैली जो व्यापक रूप से खराब और हानिकारक होने के लिए सहमत है, और/या सिर्फ सादा कार्गो-पंथ "सुरक्षा" प्रोग्रामिंग। –

संबंधित मुद्दे

 संबंधित मुद्दे