C ++ को Objective-C प्रोजेक्ट में एम्बेड करने के तरीके

यह विषय ऑब्जेक्टिव-सी परियोजनाओं में सी ++ को एम्बेड करने के तरीकों के बारे में एक लेख का मेरा अनुवाद है, जो सफल और असफल दोनों के कुछ दिलचस्प समाधानों का वर्णन करता है। मूल लेख:
www.philjordan.eu/article/strategies-for-using-c++-in-objective-c-projects

इस प्रकार,

C ++ को Objective-C प्रोजेक्ट में एम्बेड करने के तरीके

यदि आप जल्दी में हैं और हेडर फ़ाइलों को नुकसान पहुँचाए बिना ऑब्जेक्टिव-सी कक्षाओं में सी ++ ऑब्जेक्ट्स को लागू करने की समस्या के समाधान के लिए सीधे जाना चाहते हैं, ताकि उन्हें शुद्ध उद्देश्य-सी से शामिल किया जा सके, तो आप लेख के माध्यम से पिंपल हेडर पर स्क्रॉल कर सकते हैं। इस समाधान का उपयोग ~ 95% मामलों में किया जा सकता है। बाकी में समस्या का गहरा विश्लेषण और इसे हल करने के लिए अतिरिक्त तरीके हैं।

क्यों उद्देश्य-सी और सी ++ मिलाते हैं?

उद्देश्य-सी का उपयोग करना, आमतौर पर आईओएस के तहत या मैक के तहत प्रोग्रामिंग के लिए, मैं अक्सर उन स्थितियों में आता हूं जब मुझे एक परियोजना में सी ++ डालने की आवश्यकता होती है। कभी-कभी वर्तमान कार्य के लिए सबसे अच्छा पुस्तकालय सी ++ में लिखा गया था, कभी-कभी समस्या का समाधान सी ++ में अधिक आसानी से किया जा सकता है। सबसे सामान्य उदाहरण C ++ टेम्पलेट है, जो आपको डुप्लिकेट मानक कोड लिखने से बचाता है। कम स्पष्ट है कि ऑब्जेक्टिव-सी कभी-कभी ऑब्जेक्ट ओरिएंटेड भी होता है। यह "लोगों के लिए-जिनके-से-हर-वस्तु-एक-वस्तु है" के लिए विधर्म की तरह लगता है, लेकिन गैर-तुच्छ डेटा संरचनाओं के लिए मुझे अक्सर ऑब्जेक्ट ओरिएंटेशन बहुत बोझिल लगता है, और Sysn संरचनाएं भी कमजोर होती हैं। C ++ का उपयोग करना सही है।

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

Objective-C और C ++ को मिलाने का एक अन्य कारण विपरीत स्थिति है जब आपको C ++ प्रोजेक्ट से Objective-C फ़ंक्शन को कॉल करने की आवश्यकता होती है। एक सामान्य उदाहरण एक गेम या इंजन को ऐप्पल प्लेटफार्मों पर पोर्ट करना है। ऐसे मामलों में, आप नीचे वर्णित तकनीकों को भी लागू कर सकते हैं।

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

एक आम हर के लिए अग्रणी: सी

एक परियोजना में इन दो प्रोग्रामिंग भाषाओं का उपयोग करने के संभावित तरीकों में से एक उन्हें पूरी तरह से अलग करना है, जिससे उन्हें शुद्ध सी के माध्यम से बातचीत करने की अनुमति मिलती है। इस प्रकार, उनके "मिश्रण" को रोका जा सकता है। यह इस तरह दिखाई देगा: C ++ लाइब्रेरी का उपयोग करने वाला कोड .cpp फ़ाइल में स्थानांतरित हो जाता है, इंटरफ़ेस C हेडर फ़ाइल में घोषित किया जाता है, C ++ भाग इस इंटरफ़ेस को बाहरी "C" फ़ंक्शन का उपयोग करता है, और वह कोड जिसमें इंटरफ़ेस एक्सेस किया जाएगा। C शुद्ध उद्देश्य-सी (.m) है।

यह सरल मामलों में अच्छी तरह से काम करेगा, लेकिन यह अधिक संभावना है कि आपको कुछ शेल लिखना होगा। जो कोई भी खुले सी इंटरफ़ेस का उपयोग करके गतिशील रूप से भरी हुई सी ++ लाइब्रेरी के साथ अनुभव करता है, वह इस बात को अच्छी तरह जानता है।

आज, लगभग सभी उद्देश्य-सी को जीसीसी या क्लैंग का उपयोग करके संकलित किया गया है। दोनों कंपाइलर ऑब्जेक्टिव-सी ++ का समर्थन करते हैं, जिसका अर्थ है कि भाषाओं को मिलाने का एक और सुविधाजनक तरीका है।

उद्देश्य-सी ++ और हेडर फ़ाइलों के साथ समस्याएं

पहली नज़र में, उद्देश्य-सी ++ बोली का उपयोग करना सबसे सरल दृष्टिकोण की तरह दिखता है। यह सी + + और ऑब्जेक्टिव-सी को एक संकलक में एक साथ विलय करने का परिणाम है, जिसका विश्वसनीय कार्यान्वयन जीसीसी और क्लैंग दोनों में है। यह देखते हुए कि विभिन्न उद्देश्य-सी और सी ++ कैसे हैं, जीसीसी प्रोग्रामर्स ने एक कठिन काम किया है। लेकिन जैसे ही आप नाम बदलना शुरू करते हैं। मैं .m फ़ाइलों को। C ++ फ़ाइलों के रूप में घोषित करने के लिए, आपको समझ में आता है कि यह इतना सरल नहीं है।

हेडर फाइलें और सी प्रीप्रोसेसर कई वर्षों से सी, सी ++ और ऑब्जेक्टिव-सी प्रोग्रामर के लिए सिरदर्द का कारण रहे हैं, और जब आप इन भाषाओं को मिलाते हैं, तो चीजें और भी खराब हो जाती हैं। मान लीजिए कि आप उद्देश्य-सी कक्षा में एसटीएल पुस्तकालय से नक्शा कंटेनर (शब्दकोश, साहचर्य सरणी) का उपयोग करना चाहते हैं। जहां तक ​​मुझे पता है, Apple के फाउंडेशन फ्रेमवर्क में पेड़ों पर संरचनात्मक रूप से निर्मित एक छांटा हुआ नक्शा नहीं है। इसलिए, हमारी कक्षा में एक सदस्य चर बनाएं:

#include <map> @interface MyClass : NSObject { @private std::map<int, id> lookupTable; } // ... @end 

हालाँकि, std :: map <int, id> केवल एक संकलक के लिए समझ में आता है जो C ++ का समर्थन करता है, और केवल #include के बाद, इसलिए अब यह शीर्ष लेख फ़ाइल केवल उद्देश्य-सी ++ फ़ाइलों से (#import) आयात की जा सकती है। और इस वर्ग का उपयोग करने वाले किसी भी कोड को अब Objective-C ++ में बदल दिया जाना चाहिए। आगे श्रृंखला के साथ, बाकी हेडर फ़ाइलों को भी (.mm) परिवर्तित करना होगा, और इसी तरह पूरी परियोजना के साथ।

कुछ मामलों में यह स्वीकार्य है। इसके बावजूद, पूरी परियोजना या उसके अधिकांश भाग को केवल एक स्थान पर पुस्तकालय का उपयोग करने के लिए बदलना बहुत बोझिल और निरर्थक है; इसके अलावा, यदि आप उद्देश्य-सी प्रोग्रामर के बीच प्रोजेक्ट में केवल एक हैं जो C ++ जानते हैं, तो यह एक अच्छा विचार नहीं होगा। इसके अलावा, शुद्ध C ++ C संकलक में कोड संकलित करते समय समस्याएं उत्पन्न हो सकती हैं, यह शायद ही कभी होता है कि यह पूरी तरह से दर्द रहित हो जाता है। इसके अलावा, इसका मतलब है कि कोड को अन्य उद्देश्य-सी परियोजनाओं में स्वचालित रूप से पुन: उपयोग नहीं किया जा सकता है।

ज्यादातर मामलों में, शुद्ध उद्देश्य-सी या सी ++ में कोड का लाभ उठाने का तरीका उद्देश्य-सी ++ का उपयोग करना है जहां और केवल जहां आवश्यक हो। पूरी तरह से ऐसा करने के लिए, आपको प्रयास करना होगा।

अपने पैर की शूटिंग: शून्य *

यह स्पष्ट हो जाता है कि हेडर फ़ाइलों से C ++ का सब कुछ हटाने का लक्ष्य है। एक प्रकार को छिपाने के लिए एक विशिष्ट सी तरीका शून्य को इंगित करता है। यहाँ, निश्चित रूप से, यह भी काम करेगा:

 @interface MyClass : NSObject { @private //    std::map<int, id>* void* lookupTable; } // ... @end 

कोड के उन स्थानों पर जहां तालिका का उपयोग किया जाएगा, आपको एक स्पष्ट प्रकार की कास्ट का उपयोग करना होगा: static_cast <std :: map <int, id> * (लुकअपटेबल) या ((std :: map <int, id> * * लुकटेबल), जो बहुत गुस्सा आएगा। यदि कक्षा के सदस्य का वास्तविक प्रकार बदलता है, तो सभी प्रकार के रूपांतरणों को मैन्युअल रूप से बदलना होगा, और यह नाटकीय रूप से गलती करने की संभावना को बढ़ाता है। सदस्यों की संख्या में वृद्धि के साथ, सभी सही प्रकारों को याद रखना असंभव हो जाता है, और परिणामस्वरूप हमें स्थिर और गतिशील दोनों प्रकार के नुकसान मिलते हैं। कक्षा पदानुक्रम से वस्तुओं के साथ काम करने के लिए इस पद्धति का उपयोग करना आग के साथ एक खतरनाक खेल है, जिसमें यह संकेत दे सकता है कि ए * और बी * एक ही वस्तु में अलग-अलग प्रतिनिधित्व शून्य हैं *

आप बेहतर कर सकते हैं।

सशर्त संकलन

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

 #ifdef __cplusplus #include <map> #endif @interface MyClass : NSObject { @private #ifdef __cplusplus std::map<int, id>* lookupTable; #else void* lookupTable; #endif } // ... @end 

बदसूरत, लेकिन इसके साथ काम करना बहुत आसान है C ++ मानक इस बात की गारंटी नहीं देता है कि कक्षा के लिए एक पॉइंटर और शून्य के लिए एक पॉइंटर में समान मेमोरी लोकेशन (ऑब्जेक्ट, निश्चित रूप से, समान है) होगा, लेकिन Objective-C ++ एक GNU / Apple मानक नहीं है। व्यवहार में, केवल वर्चुअल फ़ंक्शंस के पॉइंटर्स एक समस्या को प्रस्तुत करते हैं जब शून्य * में परिवर्तित होता है, और जब आप ऐसा करने का प्रयास करते हैं, तो कंपाइलर ज़ोर से शपथ लेगा। यदि चिंता बनी रहती है, तो आप C- स्टाइल कास्ट के बजाय static_cast <> का उपयोग कर सकते हैं।

C अभी भी सफलतापूर्वक * किसी भी अन्य पॉइंटर को स्पष्ट रूप से बताता है, इसलिए C #ifdef सेक्शन को पॉइंटर से कॉम्प्लेक्स के साथ स्ट्रक्चर के साथ रिप्लेस करना बेहतर हो सकता है, लेकिन यूनीक और पहचाने जाने वाला नाम, उदाहरण के लिए, स्ट्रक्चर MyPreb_std_map_int_id। आप एक मैक्रो को भी परिभाषित कर सकते हैं जो कंपाइलर के आधार पर सही प्रकार की परिभाषा तक फैली हुई है:

 #ifdef __cplusplus #define OPAQUE_CPP_TYPE(cpptype, ctype) cpptype #else #define OPAQUE_CPP_TYPE(cpptype, ctype) struct ctype #endif // ... #ifdef __cplusplus #include <map> #endif @interface MyClass : NSObject { @private OPAQUE_CPP_TYPE(std::map<int, id>, cpp_std_map_int_id)* lookupTable; } // ... @end 

इस पद्धति के साथ, आप सशर्त #include C ++ हेडर से बच नहीं सकते हैं, और यह उन लोगों को भ्रमित कर सकता है जो सी ++ को नहीं जानते या पसंद नहीं करते हैं। हाँ, और यह बहुत नहीं दिखता है। सौभाग्य से, अन्य समाधान हैं।

अमूर्त वर्ग, इंटरफेस और प्रोटोकॉल

कई सी ++ प्रोग्रामर शुद्ध आभासी कार्यों से बहुत परिचित हैं, और इसलिए सार कक्षाएं। अन्य भाषाओं, जैसे कि जावा और सी #, में एक स्पष्ट "इंटरफ़ेस" अवधारणा है, जो जानबूझकर कार्यान्वयन विवरण छिपाती है। हमारे मामले में एक ही पैटर्न का उपयोग किया जा सकता है।

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

 id<MyProtocol> ref; 

अपेक्षित के बजाय:

 MyClass* ref; 

सब कुछ काम करता है, लेकिन यह आदर्श भी नहीं है।

ऑब्जेक्टिव-सी में सार कक्षाएं

तो अमूर्त वर्गों के बारे में क्या? इस भाषा में उनके लिए कोई प्रत्यक्ष मुहावरेदार समर्थन नहीं है, लेकिन यहां तक ​​कि सामान्य एनएसएसट्रिंग भी सार है, और इसे केवल इसका उपयोग करके समझना असंभव है। हमारी समस्या को हल करने का एक वैकल्पिक तरीका सभी विधि घोषणाओं को लेना और उन सभी को ऐसी कक्षा में रखना है। आपको अपूर्ण वर्ग विवरण के बारे में संकलक चेतावनी को सहना होगा। रनटाइम में, कोई भी अचूक तरीके से कॉल करने का प्रयास अपवाद नहीं करेगा। आप निश्चित रूप से, इन विधियों के छद्म-कार्यान्वयन बना सकते हैं जो विशेष अपवादों को फेंक देंगे जो स्थिति की व्याख्या करते हैं।

ज्यादातर भाषाओं में, उदाहरणों को बनाने के लिए आपको एक विशिष्ट वर्ग को जानने की जरूरत होती है, या इसे एक कक्षा कारखाने में सौंपना होता है। दिलचस्प बात यह है कि आप सीधे एनएसएसटीरिंग वर्ग को आवंटन और इनआईट संदेश भेज सकते हैं, और आप एनएसएसटीरिंग से विरासत में प्राप्त वर्गों के उदाहरण प्राप्त कर सकते हैं। Init संदेश स्वयं के अलावा किसी अन्य वस्तु को लौटाता है जिसके लिए init भेजा गया था, उदाहरण के लिए, NSString पर आवंटित को फिर से परिभाषित किया जा सकता है ताकि NSCFString को बुलाया जाए, यहां वर्ग कारखाना NSString है। यदि आप स्वयं ऐसा करते हैं, तो आपको सार के लिए एक विशेष वर्ग द्वारा उपयोग किए जाने वाले सभी init * विधियों को परिभाषित करना होगा, अन्यथा वे उन लोगों को दिखाई नहीं देंगे जो इसका उपयोग करते हैं।

इस प्रकार, एक अमूर्त वर्ग में सभी तरीकों की घोषणा करना, इससे विरासत में मिली वस्तु-सी ++ कक्षाएं निश्चित रूप से हेडर फ़ाइल के लिए और इस वर्ग का उपयोग करने वालों के लिए सबसे अधिक धूल-मुक्त समाधान है, लेकिन एक ही समय में यह सबसे अधिक समय लेने वाली है, एक अतिरिक्त वर्ग, छद्म तरीकों की आवश्यकता होती है और init के गैर-तुच्छ कार्यान्वयन।

हालाँकि, C ++ प्रोग्रामर को इस तरह की समस्याओं का एक सुरुचिपूर्ण समाधान मिला। बड़ी सी ++ परियोजनाओं की गंभीर समस्याओं में से एक है हेडर फ़ाइलों की निर्भरता के साथ नाटकीय रूप से बढ़ता संकलन समय। ऐसे मामलों में, आमतौर पर प्रोग्रामर से क्लास इंटर्नल्स का उपयोग करते हुए इसे छिपाते हैं। वास्तव में एक ही समाधान को उद्देश्य-सी / सी ++ दुविधा पर लागू किया जा सकता है।

pimpl

पिंपल - "सूचक को लागू करने के लिए" या "निजी कार्यान्वयन" के लिए छोटा। यह मुहावरा बहुत सरल है। संरचना के कार्यान्वयन का एक खुला विवरण खुले हेडर फ़ाइल में जोड़ा जाता है, आमतौर पर प्रत्यय के साथ सार्वजनिक वर्ग के नाम का उपयोग करना Impl सम्मेलन पर निर्भर करता है। इस संरचना में सभी सदस्य शामिल होंगे जिन्हें सार्वजनिक श्रेणी के हेडर फ़ाइल से छिपाया जाना आवश्यक है। यह वर्ग चर में संरचना के लिए एक संकेतक जोड़ने के लिए रहता है और संरचना के सदस्यों को .cpp फ़ाइल (हमारे मामले में, .mm) में परिभाषित करता है। कंस्ट्रक्टर (अधिक सटीक रूप से, इन -इनिट *) में, नए ऑपरेटर का उपयोग करके, आपको संरचना का एक उदाहरण बनाने की आवश्यकता है, इसे एक वर्ग चर में असाइन करें और सुनिश्चित करें कि डिलीट को -dealloc कहा जाता है।

 MyClass.h: // ... struct MyClassImpl; @interface MyClass : NSObject { @private struct MyClassImpl* impl; } //   ... - (id)lookup:(int)num; // ... @end MyClass.mm: #import "MyClass.h" #include <map> struct MyClassImpl { std::map<int, id> lookupTable; }; @implementation MyClass - (id)init { self = [super init]; if (self) { impl = new MyClassImpl; } return self; } - (void)dealloc { delete impl; [super dealloc]; } - (id)lookup:(int)num { std::map<int, id>::const_iterator found = impl->lookupTable.find(num); if (found == impl->lookupTable.end()) return nil; return found->second; } // ... @end 

सब कुछ काम करेगा, क्योंकि संरचनाओं की अग्रिम घोषणा एक वैध सी कोड है, भले ही बाद में यह पता चले कि संरचना में स्पष्ट या निहित C ++ निर्माता या यहां तक ​​कि मूल वर्ग शामिल हैं। कक्षा के सार्वजनिक तरीकों में एक पॉइंटर के माध्यम से संरचना तक पहुंच होती है, और नए / हटाए जाने का उपयोग करके सृजन और विलोपन किया जाता है।

कार्यान्वयन पर निर्भर करता है, खुले वर्ग के तरीकों में कितनी अधिक कार्यक्षमता होगी। आप प्रदर्शन में सुधार कर सकते हैं यदि, कुछ मामलों में, आप ऑब्जेक्टिव-सी संदेशों को अग्रेषित करने से बचते हैं, लेकिन उन समस्याओं को ध्यान में रखते हैं, जो सी ++ विधियों को ऑब्जेक्टिव-सी कक्षाओं को संदेश भेजने की आवश्यकता होती है।

यह ध्यान देने योग्य है कि MyClass में एक संरचना को लागू करने के बजाय, आप MyClass को इनहेरिट कर सकते हैं। इस तरह आप अप्रत्यक्ष कॉल से बच सकते हैं:

 @interface MyClass : NSObject { struct MyClassMap* lookupTable; } - (id)lookup:(int)i; @end and MyClass.mm: #import "MyClass.h" #include <map> struct MyClassMap : std::map<int, id> { }; @implementation MyClass - (id)init { self = [super init]; if (self) lookupTable = new MyClassMap; return self; } - (id)lookup:(int)i { MyClassMap::const_iterator found = lookupTable->find(i); return (found == lookupTable->end()) ? nil : found->second; } - (void)dealloc { delete lookupTable; lookupTable = NULL; [super dealloc]; } @end 

लेकिन जैसे-जैसे सदस्यों की संख्या बढ़ती है, बड़ी संख्या में नए / हटाए जाने के कारण यह अव्यावहारिक हो जाता है।

प्रतिबंध

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

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

अंत में विचार

फिर भी, मुझे लगभग सभी मामलों में उद्देश्य-सी में C ++ एम्बेड करने के लिए पिम्पल मुहावरा सबसे अच्छा विकल्प लगता है। यहां तक ​​कि अगर संरचना में केवल एक सदस्य होता है, तो अनावश्यक प्रकार के रूपांतरणों की अनुपस्थिति अप्रत्यक्षता के लिए क्षतिपूर्ति करती है। प्रदर्शन खो नहीं है, क्योंकि संरचना खुद एक सूचक नहीं है। मामले में जब आपको C ++ में ऑब्जेक्टिव-सी को सक्षम करने की आवश्यकता होती है, तो आप निम्न तरीके से ऐसा कर सकते हैं: एक ओपन सी ++ इंटरफ़ेस को परिभाषित करें, हेडर फ़ाइल में क्लास के कार्यान्वयन के लिए घोषणा से आगे और ऑब्जेक्टिव-सी सदस्यों की परिभाषा को इसी .mm फ़ाइल में डालें।