2011-11-23 12 views
5

मैं उद्देश्य सी से सी ++ से कुछ कोड पोर्ट करने की प्रक्रिया में हूं। मैं सी ++ डिजाइन पैटर्न से परिचित नहीं हूं क्योंकि मैं उद्देश्य सी के साथ हूं। कोको दुनिया में, फैक्ट्री विधि लिखने का एक बहुत ही सामान्य पैटर्न है जो "ऑटोरेलेज्ड" ऑब्जेक्ट देता है। Somethings के रूप में सरल:सी ++ में उद्देश्य सी "autorelease" - ऑब्जेक्ट जीवनकाल को नियंत्रित करने के लिए मानक तरीका?

- (MyClass *)load { 

    MyClass* obj = [[MyClass alloc] init]; 
    return [obj autorelease]; 
} 

यह समझना आसान और आसान है। विधि आवंटित स्मृति का मालिक है, लेकिन इसे वापस कॉलर को सौंप सकती है, साथ ही स्वामित्व को छोड़कर। कॉलर को उस स्मृति के साथ क्या करना है या उसे ध्यान में रखना नहीं है। यदि यह इसे बरकरार रखता है, तो वस्तु जीवित रहेगी। अगर इसे पूरी तरह नजरअंदाज कर दिया जाता है, तो वर्तमान कॉल स्टैक अवांछित होने के बाद स्मृति को कुछ समय से मुक्त कर दिया जाएगा।

मैं सी ++ में कुछ घबराहट के साथ इस आ रहा हूँ, क्योंकि अपने गैर रेफरी बार गणना वातावरण काफी के रूप में autorelease के रूप में साफ है, या उस के साथ-साथ में उन लोगों के रूप में परिभाषित किया गया है स्वामित्व नीति के किसी भी प्रकार के लिए कुछ भी दिखाई नहीं देता कोको ढांचे। सी ++ में इस तरह के पैटर्न के लिए सर्वोत्तम प्रथाएं क्या हैं?

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

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

सी का एक और विकल्प केवल वापस लौटाई गई स्मृति को जारी नहीं करेगा, लेकिन सामान्यतः अपनाया जाने वाला नामकरण सम्मेलन के माध्यम से इंगित करें कि कॉलर अब लौटा हुआ ऑब्जेक्ट का मालिक है। यह थोड़ा पुरातन लगता है, और अदृश्य लीक के लिए प्रवण है कॉलर गलती से वापसी मूल्य को अनदेखा करना चाहिए।

+2

"हालांकि मुझे यह कुछ अजीब लगता है कि इस पार्टी के लिए तीसरी पार्टी लाइब्रेरी पर दुबला होना पड़ेगा।" इस्की आद्त डाल लो। इस तरह सी ++ में चीजें की जाती हैं: आपको पुस्तकालय मिलते हैं जो आपको चाहिए, और आप उनका उपयोग करते हैं। स्मृति की स्वामित्व सी ++ में वाक्य रचनात्मक नहीं है; यह * हमेशा * मैनुअल है। –

उत्तर

8

उपयोग कर सकते हैं

  1. कुछ न करें: "सर्वोत्तम प्रथाओं" सी ++ 03 दुनिया में (जो है, पूर्व सी ++ 11) दो चीजों में से एक है। धारणा/सम्मेलन द्वारा यह अनिवार्य रूप से स्मृति स्वामित्व है। यदि कोई फ़ंक्शन पॉइंटर लौटाता है, तो आपको पता होना चाहिए कि इसका मालिक कौन है। आमतौर पर, दस्तावेज आपको बताएगा। स्मृति के स्वामित्व या स्वामित्व स्थानांतरित करने के लिए कोई विशिष्ट वाक्यविन्यास नहीं है।

    इस प्रकार दुर्भाग्यवश बड़ी संख्या में सी ++ कोड स्मृति को प्रबंधित करता है। यह काम कर सकता है, जब तक कि हर कोई जानता है कि उन्हें क्या करना चाहिए और किसके लिए जिम्मेदार है।

  2. कुछ प्रकार के स्मार्ट पॉइंटर का उपयोग करें। std::auto_ptr अजीब है, लेकिन यह हल्के वजन के बारे में है क्योंकि यह C++ 03 में मिलता है। नहीं, आप उन्हें मानक कंटेनर में नहीं रख सकते हैं, लेकिन यह स्वामित्व के एक विशिष्ट पैटर्न को परिभाषित करता है।एक boost::shared_ptr एक अधिक प्रभावी है, और कई अन्य स्थानों में अधिक उपयोगी है।

सी ++ 11 प्रस्तावों std::unique_ptr है, जो अनिवार्य है एक "स्थिर" auto_ptr। यह सी ++ 11 भाषा विशेषताओं (ऑब्जेक्ट मूवमेंट) पर निर्भर करता है, इसलिए आप सी ++ 03 में केवल एक नहीं लिख सकते हैं। आप उन्हें मानक कंटेनर और सबकुछ में स्टोर कर सकते हैं। लेकिन आप उन्हें बस पास नहीं कर सकते हैं। जैसा कि नाम से पता चलता है, वे अद्वितीय हैं: उनमें से केवल एक ही मौजूद हो सकता है जो उस ऑब्जेक्ट को इंगित करता है। जब unique_ptr नष्ट हो जाता है, तो यह उस ऑब्जेक्ट को संदर्भित करता है जो संदर्भ देता है।

आप unique_ptr का स्वामित्व केवल इसे देकर कर सकते हैं। यही है, आप स्वामित्व साझा नहीं कर सकते हैं। आप स्वामित्व वापस कर सकते हैं, जिसका मतलब है कि कॉलर के पास अब इसका मालिक है। आप किसी अन्य फ़ंक्शन पर स्वामित्व पास कर सकते हैं, जिसका अर्थ है कि उस फ़ंक्शन का स्वामित्व है। लेकिन unique_ptr के माध्यम से कोई भी दो संस्थाएं किसी ऑब्जेक्ट का स्वामित्व नहीं कर सकती हैं।

unique_ptr इस तरह के फ़ंक्शन को संभालने का पसंदीदा तरीका होगा। यदि उपयोगकर्ता इसे अनन्य रूप से स्वयं स्टोर करना चाहता है, तो वे इसे std::shared_ptr (जिसे सी ++ 11 में भी अपनाया गया था) में रिलीज़ कर सकते हैं।

3

मैं shared_ptr को बढ़ावा में देखता हूं।

सी ++ दुनिया पुस्तकालयों के बारे में है। चूंकि कोई भी सी ++ (उद्देश्य-सी के विपरीत) का मालिक है, इसलिए यह बढ़ता है क्योंकि समुदाय आवश्यकता को देखता है।

2

खैर सबसे C++ - जैसे विकल्प स्मार्ट संकेत उपयोग कर रहा है ..

मैं क्या पढ़ा से, संदर्भ गिनती संकेत, आपका सर्वश्रेष्ठ दांव हैं C++ 11 मानक में आप shared_ptr

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