C ++ में प्रतिनिधियों को लागू करने के लिए मेरा दृष्टिकोण: रनटाइम पर अज्ञात मापदंडों के साथ एक फ़ंक्शन को कॉल करना

प्रागितिहास

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

बेशक, प्रतिनिधियों की एक पूरी नकल बहुत जटिल है, इसलिए यह लेख केवल पुस्तकालय की सामान्य वास्तुकला और कुछ महत्वपूर्ण समस्याओं के समाधान को प्रदर्शित करेगा जो भाषा द्वारा सीधे समर्थित नहीं होने पर व्यवहार करते हैं।

संकलन के दौरान मापदंडों और अज्ञात प्रकारों की अनिश्चित संख्या के साथ कार्य करना

बेशक, यह सी ++ के साथ मुख्य समस्या है, जिसे हल करना इतना आसान नहीं है। बेशक, C ++ में C - varargs से विरासत में मिला एक उपकरण है, और सबसे अधिक संभावना है कि यह पहली चीज है जो दिमाग में आती है ... हालांकि, वे फिट नहीं होते हैं, सबसे पहले, उनके प्रकार-असुरक्षित प्रकृति (जैसे C से कई चीजें) के कारण। दूसरे, ऐसे तर्कों का उपयोग करते समय, आपको पहले से यह जानना होगा कि तर्क किस प्रकार के हैं। हालांकि, लगभग निश्चित रूप से, यह वैरग के साथ सभी समस्याएं नहीं हैं। सामान्य तौर पर, यह उपकरण यहां सहायक नहीं है।

और अब मैं उन उपकरणों को सूचीबद्ध करूंगा जिन्होंने इस समस्या को हल करने में मेरी मदद की।

एसटीडी :: कोई भी

C ++ 17 के साथ शुरू, भाषा में किसी भी चीज़ के लिए एक अद्भुत कंटेनर कंटेनर है - CLI में System.Object के लिए कुछ दूर की समानता :: कोई भी । यह कंटेनर वास्तव में कुछ भी स्टोर कर सकता है, और यहां तक ​​कि कैसे: कुशलता से! - मानक अनुशंसा करता है कि आप छोटी वस्तुओं को सीधे इसमें संग्रहीत करते हैं, बड़ी वस्तुओं को पहले से ही गतिशील मेमोरी में संग्रहीत किया जा सकता है (हालांकि यह व्यवहार अनिवार्य नहीं है, माइक्रोसॉफ्ट ने अपने सी ++ कार्यान्वयन में यह किया है, जो अच्छी खबर है)। और केवल इसे समानता कहा जा सकता है क्योंकि System.Object वंशानुक्रम संबंध ("a") में शामिल है, और std :: कोई भी सदस्यता संबंध में शामिल है ("a")। डेटा के अलावा, कंटेनर में ऑब्जेक्ट std :: type_info - RTTI में एक संकेतक होता है, जिसका प्रकार कंटेनर में "झूठ" है।

कंटेनर के लिए एक पूरी हेडर फ़ाइल <any> आवंटित की जाती है।

कंटेनर से किसी वस्तु को "बाहर निकालने" के लिए, आपको std :: any_cast () टेम्प्लेट फ़ंक्शन का उपयोग करना होगा, जो ऑब्जेक्ट का संदर्भ देता है।
उपयोग उदाहरण:

#include <any> void any_test() { std::any obj = 5; int from_any = std::any_cast<int>(obj); } 

यदि अनुरोधित प्रकार कंटेनर के अंदर ऑब्जेक्ट से मेल नहीं खाता है, तो एक अपवाद std :: bad_any_cast फेंक दिया जाता है ।

Std :: any , std :: bad_any_cast classes और std :: any_cast फ़ंक्शन के अलावा , शीर्ष लेख फ़ाइल में टेम्पलेट टेम्पलेट std :: make_any समान std :: make_sared , std ::_pair और इस तरह के अन्य कार्य हैं।

RTTI

निश्चित रूप से, यह सी + + में व्यावहारिक रूप से अवास्तविक होगा ताकि रनटाइम पर टाइप जानकारी के बिना एक गतिशील फ़ंक्शन कॉल को लागू किया जा सके। आखिरकार, किसी तरह यह जांचना आवश्यक है कि सही प्रकार पारित किए गए हैं या नहीं।

C ++ में आदिम RTTI का समर्थन काफी समय से है। यह सिर्फ एक बिंदु है, जो कि आदिम है - हम एक प्रकार के बारे में बहुत कम सीख सकते हैं, जब तक कि सजाए गए और अघोषित नाम न हों। इसके अलावा, हम एक दूसरे के साथ प्रकारों की तुलना कर सकते हैं।

आमतौर पर, "RTTI" शब्द का उपयोग बहुरूपता के संबंध में किया जाता है। हालाँकि, यहाँ हम इस शब्द का व्यापक अर्थ में उपयोग करेंगे। उदाहरण के लिए, हम इस तथ्य को ध्यान में रखेंगे कि प्रत्येक प्रकार में रनटाइम के प्रकार के बारे में जानकारी होती है (हालांकि आप केवल पॉलिमोर्फिक प्रकारों के विपरीत, इसे संकलित समय पर सांख्यिकीय रूप से प्राप्त कर सकते हैं)। इसलिए, रनटाइम के दौरान गैर-पॉलीमॉर्फिक प्रकार (टोटोलॉजी के लिए खेद) के प्रकारों की तुलना करना संभव (और आवश्यक) है।
RTTI को std :: type_info वर्ग का उपयोग करके एक्सेस किया जा सकता है। यह वर्ग <typeinfo> हेडर फ़ाइल में स्थित है। इस वर्ग के किसी ऑब्जेक्ट का संदर्भ केवल टाइपिड () ऑपरेटर का उपयोग करके (कम से कम अभी के लिए) प्राप्त किया जा सकता है।

टेम्पलेट्स

भाषा की एक और अत्यंत महत्वपूर्ण विशेषता जिसे हमें अपने विचारों को महसूस करने की आवश्यकता है वह है टेम्पलेट। यह उपकरण काफी शक्तिशाली और अत्यंत कठिन है, वास्तव में यह आपको संकलन समय पर कोड उत्पन्न करने की अनुमति देता है।

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

कॉल के बाद तर्क लपेटना

तो, हमारे पास एक निश्चित फ़ंक्शन है जो इनपुट के रूप में कई मापदंडों को लेता है।

मैं आपको एक कोड स्केच दिखाऊंगा जो मेरे इरादों को समझाएगा।

 #include <Variadic_args_binder.hpp> #include <string> #include <iostream> #include <vector> #include <any> int f(int a, std::string s) { std::cout << "int: " << a << "\nstring: " << s << std::endl; return 1; } void demo() { std::vector<std::any> params; params.push_back(5); params.push_back(std::string{ "Hello, Delegates!" }); delegates::Variadic_args_binder<int(*)(int, std::string), int, std::string> binder{ f, params }; binder(); } 

आप पूछ सकते हैं, यह कैसे संभव है? वर्ग नाम Variadic_args_binder आपको बताता है कि ऑब्जेक्ट फ़ंक्शन और उन तर्कों को बांधता है, जब आप इसे कॉल करते हैं। इस प्रकार, यह केवल पैरामीटर के बिना एक फ़ंक्शन के रूप में इस बाइंडर को कॉल करने के लिए बनी हुई है!
इसलिए यह बाहर दिखता है।

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

 fun_ptr(param1, param2, …, paramN); 

यह C ++ कैसे काम करता है। और यह सब बहुत जटिल है।

केवल टेम्पलेट जादू इसे संभाल सकता है!

मुख्य विचार पुनरावर्ती प्रकारों को बनाना है जो प्रत्येक घोंसले के स्तर पर तर्कों या फ़ंक्शन में से एक को स्टोर करते हैं।

इसलिए, _Tagged_args_binder वर्ग घोषित करें:

 namespace delegates::impl { template <typename Func_type, typename... T> class _Tagged_args_binder; } 

पैकेजों को आसानी से "ट्रांसफर" करने के लिए, हम एक सहायक प्रकार बनाएंगे , Type_pack_tag (यह क्यों आवश्यक था, यह जल्द ही बन जाएगा):

 template <typename... T> struct Type_pack_tag { }; 

अब हम _Tagged_args_binder वर्ग के विशेषज्ञ बनाते हैं।

प्रारंभिक विशेषज्ञताओं

जैसा कि आप जानते हैं, ताकि पुनरावृत्ति अनंत न हो, सीमा मामलों को परिभाषित करना आवश्यक है।
निम्नलिखित विशेषज्ञता प्रारंभिक हैं। सादगी के लिए, मैं केवल गैर-संदर्भ प्रकार और संदर्भ संदर्भ प्रकारों के लिए विशेषज्ञता का हवाला दूंगा।
सीधे पैरामीटर मानों के लिए विशेषज्ञता:

 template <typename Func_type, typename T1, typename... Types_to_construct> class _Tagged_args_binder<Func_type, Type_pack_tag<T1, Types_to_construct...>, Type_pack_tag<>> { public: static_assert(!std::is_same_v<void, T1>, "Void argument is not allowed"); using Ret_type = std::invoke_result_t<Func_type, T1, Types_to_construct...>; _Tagged_args_binder(Func_type func, std::vector<std::any>& args) : ap_arg{ std::move(unihold::reference_any_cast<T1>(args.at(0))) }, ap_caller_part{ func, args } { } auto operator()() { if constexpr(std::is_same_v<void, Ret_type>) { ap_caller_part(std::move(ap_arg)); return; } else { return std::forward<Ret_type>(ap_caller_part(std::move(ap_arg))); } } auto operator()() const { if constexpr (std::is_same_v<void, Ret_type>) { ap_caller_part(std::move(ap_arg)); return; } else { return std::forward<Ret_type>(ap_caller_part(std::move(ap_arg))); } } private: _Tagged_args_binder<Func_type, Type_pack_tag<Types_to_construct...>, Type_pack_tag<T1>> ap_caller_part; T1 ap_arg; }; 

Ap_arg कॉल का पहला तर्क और बाकी पुनरावर्ती ap_caller_part ऑब्जेक्ट यहां संग्रहीत है । ध्यान दें कि टी 1 प्रकार इस ऑब्जेक्ट के प्रकारों के पहले पैकेट से "स्थानांतरित" होता है और पुनरावर्ती ऑब्जेक्ट के "पूंछ" में दूसरे नंबर पर होता है।

लिंक के लिए विशेषज्ञता:

 template <typename Func_type, typename T1, typename... Types_to_construct> class _Tagged_args_binder<Func_type, Type_pack_tag<T1&&, Types_to_construct...>, Type_pack_tag<>> { using move_ref_T1 = std::add_rvalue_reference_t<std::remove_reference_t<T1>>; public: using Ret_type = std::invoke_result_t<Func_type, move_ref_T1, Types_to_construct>; _Tagged_args_binder(Func_type func, std::vector<std::any>& args) : ap_arg{ std::move(unihold::reference_any_cast<T1>(args.at(0))) }, ap_caller_part{ func, args } { } auto operator()() { if constexpr (std::is_same_v<void, Ret_type>) { ap_caller_part(std::move(unihold::reference_any_cast<T1>(ap_arg))); } else { return std::forward<Ret_type>(ap_caller_part(std::move(unihold::reference_any_cast<T1>(ap_arg)))); } } auto operator()() const { if constexpr (std::is_same_v<void, Ret_type>) { ap_caller_part(std::move(unihold::reference_any_cast<T1>(ap_arg))); } else { return std::forward<Ret_type>(ap_caller_part(std::move(unihold::reference_any_cast<T1>(ap_arg)))); } } private: _Tagged_args_binder<Func_type, Type_pack_tag<Types_to_construct...>, Type_pack_tag<move_ref_T1>> ap_caller_part; std::any ap_arg; }; 

टेम्पलेट "राइट-हैंडेड" लिंक वास्तव में राइट-हैंड अर्थ नहीं हैं। ये तथाकथित "सार्वभौमिक लिंक" हैं, जो कि T1 के प्रकार के आधार पर, T1 & , या T1 && बन जाते हैं। इसलिए, आपको वर्कअराउंड का उपयोग करना होगा: सबसे पहले, चूंकि विशेषज्ञताओं को दोनों प्रकार के लिंक के लिए परिभाषित किया जाता है (यह काफी सही ढंग से नहीं कहा गया है, पहले से बताए गए कारणों के लिए) और गैर-संदर्भ मापदंडों के लिए, जब आप टेम्पलेट को त्वरित करते हैं, तो आवश्यक विशेषज्ञता का चयन किया जाएगा, भले ही यह एक दाहिने हाथ की कड़ी हो; दूसरी बात, T1 प्रकार को पैकेज से पैकेज में स्थानांतरित करने के लिए, Move_ref_T1 के सही संस्करण का उपयोग किया जाता है , जिसे एक वास्तविक प्रतिद्वंद्विता लिंक में बदल दिया जाता है।

एक सामान्य लिंक के साथ विशेषज्ञता उसी तरह से की जाती है, आवश्यक सुधार के साथ।

अंतिम विशेषज्ञता

 template <typename Func_type, typename... Param_type> class _Tagged_args_binder<Func_type, Type_pack_tag<>, Type_pack_tag<Param_type...>> { public: using Ret_type = std::invoke_result_t<Func_type, Param_type...>; inline _Tagged_args_binder(Func_type func, std::vector<std::any>& args) : ap_func{ func } { } inline auto operator()(Param_type... param) { if constexpr(std::is_same_v<void, decltype(ap_func(std::forward<Param_type>(param)...))>) { ap_func(std::forward<Param_type>(param)...); return; } else { return std::forward<Ret_type>(ap_func(std::forward<Param_type>(param)...)); } } inline auto operator()(Param_type... param) const { if constexpr(std::is_same_v<void, Ret_type>) { ap_func(param...); return; } else { return std::forward<Ret_type>(ap_func(param...)); } } private: Func_type ap_func; }; 

यह विशेषज्ञता एक कार्यात्मक वस्तु के भंडारण के लिए जिम्मेदार है और, वास्तव में, इसके ऊपर एक आवरण है। यह अंतिम पुनरावर्ती प्रकार है।

ध्यान दें कि Type_pack_tag का उपयोग यहाँ कैसे किया जाता है। सभी पैरामीटर प्रकार अब बाएं पैकेज में संकलित किए गए हैं। इसका मतलब है कि वे सभी संसाधित और पैक किए गए हैं।

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

 template <typename Func_type, typename T1, typename... Types_to_construct, typename... Param_type> class _Tagged_args_binder<Func_type, T1, Types_to_construct..., Param_type...> { }; 

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

इंटरमीडिएट स्पेशलाइजेशन

मध्यवर्ती विशेषज्ञता से, मैं अंत में एक विशेषज्ञता दूंगा, फिर से, मूल्य प्रकारों के लिए, बाकी उपमा से है:

 template <typename Func_type, typename T1, typename... Types_to_construct, typename... Param_type> class _Tagged_args_binder<Func_type, Type_pack_tag<T1, Types_to_construct...>, Type_pack_tag<Param_type...>> { public: using Ret_type = std::invoke_result_t<Func_type, Param_type..., T1, Types_to_construct...>; static_assert(!std::is_same_v<void, T1>, "Void argument is not allowed"); inline _Tagged_args_binder(Func_type func, std::vector<std::any>& args) : ap_arg{ std::move(unihold::reference_any_cast<T1>(args.at(sizeof...(Param_type)))) }, ap_caller_part{ func, args } { } inline auto operator()(Param_type... param) { if constexpr (std::is_same_v<void, Ret_type>) { ap_caller_part(std::forward<Param_type>(param)..., std::move(ap_arg)); return; } else { return std::forward<Ret_type>(ap_caller_part(std::forward<Param_type>(param)..., std::move(ap_arg))); } } inline auto operator()(Param_type... param) const { if constexpr (std::is_same_v<void, Ret_type>) { ap_caller_part(std::forward<Param_type>(param)..., std::move(ap_arg)); } else { return std::forward<Ret_type>(ap_caller_part(std::forward<Param_type>(param)..., std::move(ap_arg))); } } private: _Tagged_args_binder<Func_type, Type_pack_tag<Types_to_construct...>, Type_pack_tag<Param_type..., T1>> ap_caller_part; T1 ap_arg; }; 

इस विशेषज्ञता का उद्देश्य पहले को छोड़कर किसी भी तर्क को पैक करना है।

बाइंडर क्लास

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

 namespace cutecpplib::delegates { template <typename Functor_type, typename... Param_type> class Variadic_args_binder { using binder_type = impl::_Tagged_args_binder<Functor_type, Type_pack_tag<Param_type...>, Type_pack_tag<>>; public: using Ret_type = std::invoke_result_t<binder_type>; inline Variadic_args_binder(Functor_type function, Param_type... param) : ap_tagged_binder{ function, param... } { } inline Variadic_args_binder(Functor_type function, std::vector<std::any>& args) : ap_tagged_binder{ function, args } { } inline auto operator()() { return ap_tagged_binder(); } inline auto operator()() const { return ap_tagged_binder(); } private: binder_type ap_tagged_binder; }; } 

Unihold कन्वेंशन - std के अंदर पासिंग लिंक :: कोई भी

एक चौकस पाठक ने देखा होगा कि कोड unihold :: reference_any_cast () फ़ंक्शन का उपयोग करता है। यह फ़ंक्शन, साथ ही इसके एनालॉग यूनीहोल्ड :: पॉइंटर_न्य_कास्ट () , को लाइब्रेरी समझौते को लागू करने के लिए डिज़ाइन किया गया है: संदर्भ द्वारा पारित किए जाने वाले तर्कों को पॉइंटर द्वारा std :: any द्वारा पारित किया जाना चाहिए।

संदर्भ_या_कास्ट फ़ंक्शन हमेशा किसी ऑब्जेक्ट का संदर्भ देता है, चाहे वह ऑब्जेक्ट कंटेनर में संग्रहीत हो या केवल एक पॉइंटर हो। यदि std :: किसी वस्तु में कोई वस्तु समाहित है, तो इस वस्तु का एक संदर्भ कंटेनर के अंदर वापस आ जाता है; यदि इसमें एक पॉइंटर होता है, तो पॉइंटर द्वारा इंगित ऑब्जेक्ट पर एक संदर्भ दिया जाता है।

प्रत्येक फ़ंक्शन के लिए, निरंतर std :: किसी भी और अतिभारित संस्करणों के लिए विकल्प हैं यह निर्धारित करने के लिए कि कंटेनर std :: किसी भी वस्तु का मालिक है या केवल एक पॉइंटर है।

फ़ंक्शंस को स्टोर किए गए ऑब्जेक्ट के प्रकार में स्पष्ट रूप से विशेष करने की आवश्यकता होती है, जैसे सी ++ प्रकार रूपांतरण और समान टेम्पलेट फ़ंक्शन।

इन कार्यों के लिए कोड:

 template <typename T> std::remove_reference_t<T>& unihold::reference_any_cast(std::any& wrapper) { bool result; return reference_any_cast<T>(wrapper, result); } template <typename T> const std::remove_reference_t<T>& unihold::reference_any_cast(const std::any& wrapper) { bool result; return reference_any_cast<T>(wrapper, result); } template <typename T> std::remove_reference_t<T>& unihold::reference_any_cast(std::any& wrapper, bool& is_owner) { auto ptr = pointer_any_cast<T>(&wrapper, is_owner); if (!ptr) throw std::bad_any_cast{ }; return *ptr; } template <typename T> const std::remove_reference_t<T>& unihold::reference_any_cast(const std::any& wrapper, bool& is_owner) { auto ptr = pointer_any_cast<T>(&wrapper, is_owner); if (!ptr) throw std::bad_any_cast{ }; return *ptr; } template <typename T> std::remove_reference_t<T>* unihold::pointer_any_cast(std::any* wrapper, bool& is_owner) { using namespace std; using NR_T = remove_reference_t<T>; // No_reference_T //     wrapper NR_T** double_ptr_to_original = any_cast<NR_T*>(wrapper); //      wrapper NR_T* ptr_to_copy; if (double_ptr_to_original) { // Wrapper      is_owner = false; return *double_ptr_to_original; } else if (ptr_to_copy = any_cast<NR_T>(wrapper)) { // Wrapper    is_owner = true; return ptr_to_copy; } else { throw bad_any_cast{}; } } template <typename T> const std::remove_reference_t<T>* unihold::pointer_any_cast(const std::any* wrapper, bool& is_owner) { using namespace std; using NR_T = remove_reference_t<T>; // No_reference_T //     wrapper NR_T*const * double_ptr_to_original = any_cast<NR_T*>(wrapper); //      wrapper const NR_T* ptr_to_copy; //remove_reference_t<T>* ptr2 = any_cast<remove_reference_t<T>>(&wrapper); if (double_ptr_to_original) { // Wrapper      is_owner = false; return *double_ptr_to_original; } else if (ptr_to_copy = any_cast<NR_T>(wrapper)) { // Wrapper    is_owner = true; return ptr_to_copy; } else { throw bad_any_cast{}; } } template <typename T> std::remove_reference_t<T>* unihold::pointer_any_cast(std::any* wrapper) { bool result; return pointer_any_cast<T>(wrapper, result); } template <typename T> const std::remove_reference_t<T>* unihold::pointer_any_cast(const std::any* wrapper) { bool result; return pointer_any_cast<T>(wrapper, result); } 

निष्कर्ष

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

PS RTTI का उपयोग करके अगले भाग में प्रदर्शित किया जाएगा।