2013-11-26 7 views
6

उनके रिटर्न प्रकार को बदलने की आवश्यकता होने पर कार्यों को बहिष्कृत करने के लिए क्या रणनीतियां हैं? उदाहरण के लिए, मेरे पास है:रिटर्न प्रकार बदलते समय फ़ंक्शन को कैसे हटाया जाए C++

BadObject foo(int); // Old function: BadObject is being removed. 
Object foo(int); // New function. 

Object और BadObject आंतरिक रूप से बहुत अलग हैं, और उनकी वापसी प्रकार की अदला-बदली मेरे पुस्तकालय की वर्तमान उपयोगकर्ताओं के लिए कोड टूट जाएगा। मैं इससे बचने का लक्ष्य रख रहा हूं।

मैं BadObject foo(int) deprecated को चिह्नित कर सकता हूं, और उपयोगकर्ताओं को प्रभावित कोड बदलने के लिए समय देता हूं।
हालांकि, मैं can't overload foo based on return-typefoo बहुत अच्छी तरह से नामित है, और इसे अतिरिक्त पैरामीटर लेने की आवश्यकता नहीं है। कम से कम थोड़ी देर के लिए पुराने संस्करण को बनाए रखने के दौरान, मैं अपनी लाइब्रेरी में नया फ़ंक्शन कैसे जोड़ सकता हूं?

उपयोगकर्ताओं को नए संस्करण में माइग्रेट करने का समय प्रदान करते समय पुराने फ़ंक्शन को तोड़ने के बिना पुराने फ़ंक्शन को बहिष्कृत करने की रणनीति क्या है? आदर्श रूप से मैं वर्तमान फ़ंक्शन नाम और पैरामीटर सूची रखूंगा, क्योंकि इसका नाम अब बहुत अच्छा है। ऐसा लगता है कि इस एक सामान्य समस्या हो सकती है: इसे हल करने का एक अच्छा तरीका क्या है?

+0

ठीक है, यदि उपयोगकर्ता मैन्युअल रूप से रिटर्न प्रकार टाइप करने के बजाय ऑटो का उपयोग करते हैं, तो सबकुछ स्वचालित रूप से काम करेगा :)। – ScarletAmaranth

+0

यह आपकी मदद नहीं करता है, लेकिन सी ++ 11 इनलाइन नेमस्पेस इसके लिए बिल्कुल सही हैं। 'इनलाइन नेमस्पेस v0' में' foo' घोषित करें, जब एक परिवर्तन की आवश्यकता है 'इनलाइन नेमस्पेस v1' में' foo '' घोषित करें (और 'v0' से' इनलाइन' को हटाएं)। – mythagel

उत्तर

4

हालांकि समाधान आपको अपने फ़ंक्शन नाम बदलने के लिए मजबूर करेगा, लेकिन यह आपके पुराने उपयोगकर्ताओं और आपके नए लोगों के बीच एक समझौता होगा।

तो - पुराने foo को deprecatedFoo में बदलें और अपने नए foofoo2 (या जो भी आप चाहते हैं) में नाम बदलें। फिर, हेडर फाइल में आप अपने पुस्तकालय के साथ शामिल हैं, तो आप बस कर सकते हैं:

#define deprecatedFoo foo 

और समारोह के अंदर ही कार्य करें:

#warning ("This function is deprecated. Use 'foo2' or change the #define in LINE in file HEADER.") 

पुराने संस्करणों के उपयोगकर्ताओं को अपने कोड बदलने की जरूरत नहीं होगी , और एक चेतावनी जारी की जाएगी, और नए उपयोगकर्ता शायद foo का उपयोग करने के लिए #define को सुन और बदल देंगे।

अगले संस्करण में आप पुराने foo और define हटा देंगे।

+1

क्या आपका मतलब था कि '# परिभाषित' दूसरी तरफ? जैसा कि, नए फ़ंक्शन के उपयोगकर्ताओं को पुरानी फ़ंक्शन के उपयोगकर्ताओं के रूप में चेतावनियों की एक ही संख्या मिल जाएगी। – aschepler

+0

नए संस्करण के उपयोगकर्ताओं को चेतावनी मिलनी चाहिए, इसलिए वे (यदि वे चाहते हैं) बदल सकते हैं। यदि आपने विपरीत तरीके से '# परिभाषित किया है, तो कोड पुराने संस्करणों के साथ संगत नहीं होगा। लेकिन मुझे लगता है कि यह एक विकल्प है जिसे ओपी को करना होगा, और हम इस पर चर्चा करने वाले नहीं हैं। –

0

मुझे लगता है कि एक क्लासिक उदाहरण Boost's Spirit है।

उनके FAQ से:

जबकि आत्मा V2 शुरू हम क्रम में निर्देशिका संरचना का पुनर्गठन एक ही समय में दो संस्करणों को समायोजित करने के। Spirit.Classic सब के सब अब निर्देशिका में रहती है

बढ़ावा/भावना/घर/क्लासिक

जहां निर्देशिका के ऊपर स्थित नया स्थान आवेदन संगतता बनाए रखने के लिए अनुमति देने के लिए अग्रेषण हेडर होते हैं। अग्रेषण हेडर एक चेतावनी जारी करते हैं (बूस्ट V1.38 से शुरू) उपयोगकर्ता को उनके पथ शामिल करने के लिए बताते हैं। कृपया उपरोक्त जाने के लिए उपर्युक्त निर्देशिका/अग्रेषण शीर्षलेखों की अपेक्षा करें।

इस निर्देशिका

बढ़ावा/भावना के लिए की जरूरत बताते हैं/

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

आप नए और पुराने संस्करणों को अलग-अलग निर्देशिकाओं में रखते हुए और संगतता बनाए रखने के लिए अग्रेषण हेडर का उपयोग करके माइग्रेशन को कम कर सकते हैं। अंततः उपयोगकर्ताओं को नए शीर्षकों का उपयोग करने के लिए मजबूर किया जाएगा।

एसडीएल 2.0 का एक अलग दृष्टिकोण है। वे एक संगतता परत प्रदान नहीं करते हैं बल्कि इसके बजाय माइग्रेशन गाइड उपयोगकर्ताओं को सबसे नाटकीय परिवर्तनों के माध्यम से चलते हैं। इस मामले में, आप उपयोगकर्ताओं को यह समझने में सहायता कर सकते हैं कि उन्हें अपने कोड को पुन: व्यवस्थित करने की आवश्यकता है।

0

क्या Object वर्ग BadObject (जो आप अस्थायी रूप से रखेंगे) से प्राप्त करने के लिए क्या होगा? तब पुराने उपयोगकर्ता कोड को इसके बारे में पता नहीं चलेगा, इसलिए यह तोड़ नहीं देगा कि आपका नया "foo" फ़ंक्शन अभी भी आपकी ऑब्जेक्ट्स को सही तरीके से देता है।

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