सी ++ इंटरफ़ेस डिज़ाइन

Question

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

मेरा एप्लिकेशन एसटीएल का उपयोग करता है, और मेरी साझा लाइब्रेरी एसटीएल का भी उपयोग करती है। यहां पहली समस्या यह है कि मेरी साझा लाइब्रेरी एसटीएल का उपयोग कर रही है। यदि मैंने कभी भी अपने आवेदन में एसटीएल का एक नया संस्करण बनाया है, लेकिन मैं अपनी साझा लाइब्रेरी का पुनर्निर्माण नहीं करता क्योंकि यह आवश्यक नहीं है, तो हमारे पास तुरंत संगतता समस्याएं होंगी।

इस मुद्दे को हल करने के लिए मेरा पहला विचार साझा लाइब्रेरी कक्षाओं में इंटरफ़ेस में एसटीएल का उपयोग नहीं करना है। मान लें कि हमारे पास मेरी लाइब्रेरी में एक फ़ंक्शन है जो एक स्ट्रिंग लेता है और इसके साथ कुछ करता है।

void DoStuffWithStrings(char const* str); 

बजाय

:: मैं समारोह प्रोटोटाइप देखो की तरह होगा

void DoStuffWithStrings(std::string const& str); 

तार के लिए यह शायद एसटीएल के विभिन्न संस्करणों के बीच ठीक हो जाएगा, लेकिन नकारात्मक पक्ष यह है कि हम std::string से जा रहे हैं, char* पर, और std::string पर, जो ऐसा लगता है कि प्रदर्शन के मुद्दों का कारण बनता है।

क्या उनके एसटीएल समकक्षों को कच्चे प्रकार के मुक्केबाजी/अनबॉक्सिंग की सिफारिश की जाती है? जब हम std::list पर ऐसा करने का प्रयास करते हैं तो यह और भी बदतर हो जाता है, क्योंकि वास्तव में कोई "कच्चा प्रकार" नहीं है, मुझे पता है कि हम इसे आसानी से पास कर सकते हैं क्योंकि बिना किसी प्रकार के ओ (एन) या इसी तरह के ऑपरेशन किए।

इस परिदृश्य में कौन से डिज़ाइन सबसे अच्छे काम करते हैं? प्रत्येक के पेशेवर/विपक्ष क्या हैं?

Answer 1

const char* दृष्टिकोण के पेशेवरों में से एक यह है कि आपकी लाइब्रेरी सी से भी कॉल करने योग्य होगी, और इसलिए सी के साथ इंटरफेसिंग करने वाले कई अन्य लागेजों से भी (काफी कुछ सब कुछ बाहर)। यह अकेला एक बहुत ही रोचक बिक्री बिंदु है।

हालांकि, यदि आप दोनों पुस्तकालयों को लिखते और बनाए रखते हैं, और उनका उपयोग केवल सी ++ में किया जाएगा (अगले 5 वर्षों के लिए कहें), मैं सबकुछ बदलने की परेशानी से गुजरना नहीं चाहूंगा। std::string एक बात है, std::vector या std::map अच्छी तरह से परिवर्तित नहीं होगा। इसके अलावा, आप दूसरे एसटीएल कार्यान्वयन में कितनी बार जाते हैं? और उन मामलों में, क्या आप वास्तव में अपनी साझा लाइब्रेरी को पुनर्निर्माण के लिए 'भूल' जा रहे हैं? इसके अलावा, यदि आप वास्तव में आवश्यक हो तो भी आप बाद में सी स्टाइल रैपर लिख सकते हैं/उत्पन्न कर सकते हैं।

निष्कर्ष (इस मामले के साथ मेरे अनुभवों की ओर पक्षपात): यदि आपको सी की आवश्यकता नहीं है, तो stl के साथ जाएं।

Answer 2

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

// this: 
int MyFunc(char* Param1, int Param2, bool Param3); 

// into this: 
struct MyParams 
{ 
    char* Param1; 
    int Param2; 
    bool Param3; 
} 

// "Params" its really "struct MyParams*" 
int MyFunc(void* Params); 

और कभी-कभी एक साझा लाइब्रेरी समारोह कई तर्क है तो वह एक सूचक को बदल दिया, taht किसी सरणी या संरचना या यहां तक ​​कि एक वर्ग के लिए एक सूचक होने की उम्मीद है।

यह निर्भर करता है कि आप अपनी लाइब्रेरी के साथ कैसे काम करने जा रहे हैं, क्योंकि कई पुस्तकालयों को सादा सी की तरह उपयोग किया जाता है, भले ही आप सी ++ का उपयोग कर रहे हों।

Answer 3

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

Answer 4

लाइब्रेरी एप्लिकेशन की तुलना में एक अलग ढेर का उपयोग करती है तो एक और समस्या आ सकती है। यदि यह मामला है या मामला हो सकता है, तो सुनिश्चित करें कि पुस्तकालय अपनी याददाश्त का मालिक/प्रबंधन करता है। एकाधिक ढेर एक मुद्दा हो सकते हैं जब पुस्तकालय एक अलग सी-पुस्तकालय का उपयोग करता है और इसलिए एक अलग malloc/मुक्त और इसलिए एक अलग ढेर। सी के साथ http://msdn.microsoft.com/en-us/library/ms810466.aspx