👩‍❤️‍👨 🚶 🛌🏾 हम फ़ंक्शन का आविष्कार करना जारी रखते हैं 🍞 👩‍🔧 🧒🏻

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

कार्य क्या है और दूसरा क्यों लिखें

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

खोज जारी रखने के लिए प्रेरणा

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

खुद के कार्यान्वयन

समस्या को हल करने के लिए, C ++ 11 भाषा का उपयोग किया जाता है। कोड Xcode 4.5.2 में सत्यापित किया गया। विजुअल स्टूडियो 2012 में C ++ 11 का कार्यान्वयन देर से होता है, लेकिन नवंबर 2012 कंपाइलर CTP को स्थापित करते समय , आप उदाहरण के निर्माण के लिए आवश्यक समर्थन स्तर प्राप्त कर सकते हैं, हालांकि पूर्ण व्यावहारिक अनुप्रयोग की कोई बात नहीं है। कोड में संगतता के लिए VS2012 की ओर थोड़ा सा इशारा है। यदि आवश्यक हो, तो कोड की मात्रा में महत्वपूर्ण वृद्धि की कीमत पर समाधान को C ++ 03 के लिए फिर से लिखा जा सकता है, लेकिन मुख्य लाभ को बनाए रखना होगा।
मैं अंत से शुरू करूँगा। एक दूरगामी उपयोग के मामले की तरह लग सकता है:

#include <iostream> #include <vector> #include "function.hpp" int foo(int v) { std::cout << "foo: " << v << std::endl; return v; } struct bar { int baz(int v) { std::cout << "bar::baz: " << v << std::endl; return v; } }; int main() { //         typedef bc::function<int (int)> function_ptr; std::vector<function_ptr> functions; //     functions.push_back(BC_BIND(&foo)); //   -       bar obj; functions.push_back(BC_BIND(&bar::baz, &obj)); int i = 0, c = 0; for (auto f : functions) c += f ? f(++i) : 0; std::cout << "result: " << c << std::endl; }

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

 function<return_type (...)> function_ptr; return_type free_function(...); class Class { return_type member_function(...); };

ऐसा लगता है, लेकिन ऐसा नहीं है। दूसरी विधि परिवर्तित करें:

 return_type member_function_wrapper(Class *context, ...) { return context->member_function(...); }

पहले से बेहतर है। एक और पुनरावृत्ति:

 return_type free_function_wrapper(void *unused, ...) { return free_function(...); } return_type member_function_wrapper(void *context, ...) { return static_cast<Class*>(context)->member_function(...); }

महान, दोनों कार्य, free_function_wrapper और member_function_wrapper के एक ही हस्ताक्षर हैं। यदि पहले एक के साथ कोई प्रश्न नहीं होना चाहिए, तो दूसरे के लिए यह समझना बाकी है कि कक्षा की जानकारी और सूचक को उसके संदर्भ में सदस्य फ़ंक्शन में कैसे दर्ज किया जाए। और ऐसा अवसर उन टेम्पलेट्स के लिए भी मौजूद है, जिन्हें न केवल प्रकार और संकलन समय के अभिन्न अंग द्वारा, बल्कि कार्यों और सदस्य कार्यों के पते द्वारा भी परिमाणित किया जा सकता है। एक सरल सार उदाहरण:

 #include <iostream> struct bar { int baz(int v) { std::cout << "bar::baz: " << v << std::endl; return v; } }; template <typename Class, int (Class::*MemberFunctionPtr)(int)> int function_wrapper(void *self, int v) { return (static_cast<Class*>(self)->*MemberFunctionPtr)(v); } int main() { typedef int (*function_ptr)(void*, int); function_ptr f = &function_wrapper<bar, &bar::baz>; bar obj; int const i = f(&obj, 1); std::cout << "result: " << i << std::endl; }

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

function.hpp

 #pragma once //#define BC_NO_EXCEPTIONS #include <utility> #include <functional> #define BC_SUBST(Arg) Arg #define BC_BIND_DISAMBIGUATE2(has_args, ...) BC_SUBST(BC_BIND_ ## has_args (__VA_ARGS__)) #define BC_BIND_DISAMBIGUATE(has_args, ...) BC_BIND_DISAMBIGUATE2(has_args, __VA_ARGS__) #define BC_HAS_ARGS_IMPL(TWO, ONE, N, ...) N #define BC_HAS_ARGS(...) BC_SUBST(BC_HAS_ARGS_IMPL(__VA_ARGS__, 2, 1, ERROR)) #define BC_BIND(...) BC_BIND_DISAMBIGUATE(BC_HAS_ARGS(__VA_ARGS__), __VA_ARGS__) #define BC_BIND_1(fp) bc::detail::bind<decltype(fp), fp>() #define BC_BIND_2(mf, ip) bc::detail::bind<decltype(mf), mf>(ip) namespace bc // bicycle { template <typename Signature> class function; namespace detail { template <typename Signature> struct function_traits; template <typename ReturnType, typename ...ArgumentTypes> struct function_traits<ReturnType (*)(ArgumentTypes...)> { //typedef ReturnType (*Signature)(ArgumentTypes...); // MS error C3522: parameter pack cannot be expanded in this context typedef function<ReturnType (ArgumentTypes...)> function_type; template <typename Signature, Signature fp> static ReturnType wrapper(void const *, ArgumentTypes&& ... args) { return (*fp)(std::forward<ArgumentTypes>(args)...); } }; template <typename ReturnType, typename Class, typename ...ArgumentTypes> struct function_traits<ReturnType (Class::*)(ArgumentTypes...)> { //typedef ReturnType (Class::*Signature)(ArgumentTypes...); // MS error C3522: parameter pack cannot be expanded in this context typedef Class * class_ptr; typedef function<ReturnType (ArgumentTypes...)> function_type; template <typename Signature, Signature mf> static ReturnType wrapper(const void *ip, ArgumentTypes&& ... args) { Class* instance = const_cast<Class*>(static_cast<Class const *>(ip)); return (instance->*mf)(std::forward<ArgumentTypes>(args)...); } }; template <typename ReturnType, typename Class, typename ...ArgumentTypes> struct function_traits<ReturnType (Class::*)(ArgumentTypes...) const> { //typedef ReturnType (Class::*Signature)(ArgumentTypes...) const; // MS error C3522: parameter pack cannot be expanded in this context typedef const Class * class_ptr; typedef function<ReturnType (ArgumentTypes...)> function_type; template <typename Signature, Signature mf> static ReturnType wrapper(void const *ip, ArgumentTypes&& ... args) { Class const *instance = static_cast<Class const *>(ip); return (instance->*mf)(std::forward<ArgumentTypes>(args)...); } }; // bind free function template <typename Signature, Signature fp> typename function_traits<Signature>::function_type bind() { typedef function_traits<Signature> traits; return typename traits::function_type(&traits::template wrapper<Signature, fp>, 0); } // bind member function template <typename Signature, Signature mf> typename function_traits<Signature>::function_type bind(typename function_traits<Signature>::class_ptr ip) { typedef function_traits<Signature> traits; return typename traits::function_type(&traits::template wrapper<Signature, mf>, ip); } } template <typename ReturnType, typename ...ArgumentTypes> class function<ReturnType (ArgumentTypes...)> { typedef ReturnType (*StaticFuncPtr)(void const*, ArgumentTypes&& ...); public: function() : func_(0), data_(0) {} function(StaticFuncPtr f, void const *d) : func_(f), data_(d) {} ReturnType operator () (ArgumentTypes... args) const { #ifndef BC_NO_EXCEPTIONS if (!func_) throw std::bad_function_call(); #endif // BC_NO_EXCEPTIONS return (*func_)(data_, std::forward<ArgumentTypes>(args)...); } explicit operator bool() const { return 0 != func_; } bool operator == (function const &other) const { return func_ == other.func_ && data_ == other.data_; } bool operator != (function const &other) const { return !(*this == other); } private: StaticFuncPtr func_; void const *data_; }; }

हम फ़ंक्शन का आविष्कार करना जारी रखते हैं

कार्य क्या है और दूसरा क्यों लिखें

खोज जारी रखने के लिए प्रेरणा

खुद के कार्यान्वयन

More articles: