ROM और स्थिर चर में वस्तुओं को रखने वाला सिंगलटन (उदाहरण के रूप में कोर्टेक्स M4 माइक्रोकंट्रोलर का उपयोग करके C ++)

पिछले लेख में, कॉर्टेक्सएम माइक्रोकंट्रोलर (उदाहरण के रूप में C ++ IAR कंपाइलर का उपयोग करके) पर आपके स्थिरांक कहाँ संग्रहीत हैं, ROM में निरंतर वस्तुओं को कैसे रखा जाए, इस सवाल पर चर्चा की गई। अब, मैं आपको यह बताना चाहता हूं कि आप रोम में वस्तुओं को बनाने के लिए अकेले जनरेटर पैटर्न का उपयोग कैसे कर सकते हैं।

परिचय

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

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

सिंगलटन आपको इस बात की गारंटी भी देगा कि पोर्ट लेग का वर्णन करने वाली एक ही वस्तु को दो बार नहीं बनाया जाएगा यदि इसे अचानक कई स्थानों पर उपयोग किया जाता है।

एक और, मेरी राय में, सिंगलटन की एक उल्लेखनीय संपत्ति इसके उपयोग में आसानी है। उदाहरण के लिए, बाधा हैंडलर के मामले में, एक उदाहरण जिसके साथ लेख के अंत में है। लेकिन अभी के लिए, हम खुद सिंगलटन के साथ सौदा करेंगे।

रैम में ऑब्जेक्ट बनाने वाला सिंगलटन

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

• फर्मवेयर में गतिशील रूप से ऑब्जेक्ट बनाने की अनुशंसा नहीं की जाती है
• अक्सर फर्मवेयर में, एक ऑब्जेक्ट को सांख्यिकीय रूप से बनाया जाता है और कभी नष्ट नहीं किया जाता है।
• ठीक है, अगर ऑब्जेक्ट का स्थान संकलन चरण में जाना जाता है

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

template <typename T> class Singleton { public: static T & GetInstance() { static T instance ; return instance ; } Singleton() = delete ; Singleton(const Singleton<T> &) = delete ; const Singleton<T> & operator=(const Singleton<T> &) = delete ; } ; 

यह विलंबित प्रारंभ का उपयोग करता है, अर्थात किसी ऑब्जेक्ट का प्रारंभ केवल पहली बार GetInstance() कहलाता है, इसे डायनामिक इनिशियलाइज़ेशन मानते हैं।

 int main() { //   Timer1      auto& objRef = Singleton<Timer1>::GetInstance(); //  ,      auto& objRef1 = Singleton<Timer1>::GetInstance(); return 0; } 

और विलम्ब के बिना सिंगलटन:

 template <typename T> class Singleton { public: static constexpr T & GetInstance() { return instance ; } Singleton() = delete ; Singleton(const Singleton<T> &) = delete ; const Singleton<T> & operator=(const Singleton<T> &) = delete ; private: inline static T instance ; //      } ; 

दोनों सिंगलटन रैम में ऑब्जेक्ट बनाते हैं, अंतर यह है कि दूसरे के लिए, प्रोग्राम शुरू होने के तुरंत बाद इनिशियलाइज़ेशन होता है, और पहले कॉल पर इनिशियलाइज़ किया जाता है।

वास्तविक जीवन में उनका उपयोग कैसे किया जा सकता है। पुरानी परंपरा के अनुसार, मैं एक एलईडी के उदाहरण का उपयोग करके यह दिखाने की कोशिश करूंगा। तो, मान लीजिए कि हमें वर्ग Led1 की एक वस्तु बनाने की आवश्यकता है, जो वास्तव में कक्षा Pin<PortA, 5> :

 using PortA = Port<GpioaBaseAddr> ; using Led1 = Pin<PortA, 5> ; using GreenLed = Pin<PortA, 5> ; Led1 myLed ; //        RAM constexpr GreenLed greenLed ; //        ROM int main() { static GreenLed myGreenLed ; //     RAM Led1 led1; //     myGreenLed.Toggle(); led1.Toggle() ; } 

उदाहरण में, मैंने RAM और ROM में एक ही प्रकार की 4 विभिन्न वस्तुओं के रूप में बनाया, जो वास्तव में पोर्ट ए के समान आउटपुट के साथ काम करते हैं जो यहां बहुत अच्छा नहीं है:
खैर, पहली बात यह है कि मैं स्पष्ट रूप से भूल गया था कि GreenLed और Led1 1 एक ही प्रकार के हैं और कई समान वस्तुओं को अलग-अलग पतों पर जगह बना रहे हैं। वास्तव में, मैं यह भी भूल गया कि मैंने पहले से ही Led1 और GreenLed की विश्वव्यापी वस्तुओं को बनाया था, और उन्हें स्थानीय स्तर पर भी बनाया।

दूसरा, आम तौर पर वैश्विक वस्तुओं की घोषणा का स्वागत नहीं है,


और स्थानीय वस्तुएँ मुख्य () फ़ंक्शन के दायरे में ही उपलब्ध हैं।

इसलिए, हम सिंगलटन का उपयोग करके इस उदाहरण को फिर से लिखते हैं:

 using PortA = Port<GpioaBaseAddr> ; using Led1 = Pin<PortA, 5> ; using GreenLed = Pin<PortA, 5> ; int main() { //        GreenLed //   GreenLed& myGreenLed = Singleton<GreenLed>::GetInstance(); //            Led1& led1 = Singleton<Led1>::GetInstance(); myGreenLed.Toggle() ; led1.Toggle() ; //  , Singleton<Led1>::GetInstance().Toggle() } 

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

स्थैतिक वस्तु

पता लगाने से पहले, यह समझना अच्छा होगा कि एक स्थिर वस्तु क्या है।

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

जब एक वस्तु घोषणा में उपयोग किया जाता है, तो स्थिर विनिर्देशक केवल वस्तु के जीवनकाल को निर्धारित करता है। मोटे तौर पर, इस तरह की वस्तु के लिए मेमोरी को कार्यक्रम शुरू होने पर आवंटित किया जाता है और कार्यक्रम समाप्त होने पर मुक्त कर दिया जाता है; जब यह शुरू होता है, तो उनका प्रारंभ भी होता है। अपवाद केवल स्थानीय स्थिर वस्तुएं हैं, जो, हालांकि वे केवल कार्यक्रम के अंत में "मर" जाते हैं, अनिवार्य रूप से "जन्म" हैं, या बल्कि, पहली बार उनके घोषणा के माध्यम से गुजरने वाले प्रारंभिक हैं।

स्थैतिक भंडारण के साथ एक स्थानीय चर का गतिशील आरंभीकरण पहली बार इसकी घोषणा के माध्यम से पहली बार किया जाता है; इस तरह के एक चर को इसके आरंभ के पूरा होने पर आरंभीकृत माना जाता है। यदि एक धागा दूसरे सूत्र द्वारा इसके आरंभ होने के क्षण में परिवर्तनशील घोषणा से गुजरता है, तो इसे आरंभ के पूरा होने की प्रतीक्षा करनी चाहिए।

निम्न कॉल में, प्रारंभ नहीं होता है। उपरोक्त सभी को एक वाक्यांश में कम किया जा सकता है, एक स्थिर वस्तु का केवल एक उदाहरण मौजूद हो सकता है।

इस तरह की कठिनाइयां इस तथ्य को जन्म देती हैं कि फर्मवेयर में स्थानीय स्थिर चर और वस्तुओं के उपयोग से अतिरिक्त ओवरहेड हो जाएगा। आप इसे एक साधारण उदाहरण से सत्यापित कर सकते हैं:

 struct Test1{ Test1(int value): j(value) {} int j; } ; Test1 &foo() { static Test1 test(10) ; return test; } int main() { for (int i = 0; i < 10; ++i) { foo().j ++; } return 0; } 

यहां, पहली बार foo() फ़ंक्शन को कॉल किया जाता है, कंपाइलर को यह जांचना होगा कि स्थानीय स्थिर ऑब्जेक्ट test1 को अभी तक इनिशियलाइज़ नहीं किया गया है और Test1(10) ऑब्जेक्ट के कंस्ट्रक्टर को कॉल करें, और दूसरे और बाद के पास में, यह सुनिश्चित करना होगा कि ऑब्जेक्ट पहले से ही इनिशियलाइज़ हो गया है और इस स्टेप को छोड़ दें। return test करने के लिए सीधे जा रहे हैं।

ऐसा करने के लिए, कंपाइलर अतिरिक्त सुरक्षात्मक फ्लैग foo()::static guard for test 0x00100004 0x1 Data Lc main.o और सत्यापन कोड सम्मिलित करता है। स्थैतिक चर की पहली घोषणा में, यह सुरक्षात्मक ध्वज सेट नहीं होता है और इसलिए निर्माणकर्ता को कॉल करके ऑब्जेक्ट को आरंभीकृत किया जाना चाहिए; अगले पास के दौरान, यह ध्वज पहले से ही सेट है, इसलिए अब आरंभीकरण की कोई आवश्यकता नहीं है और कंस्ट्रक्टर कॉल को छोड़ दिया गया है। इसके अलावा, यह चेक लूप के लिए लगातार किया जाएगा।



और यदि आप उस विकल्प को सक्षम करते हैं जो आपको बहु-थ्रेडेड अनुप्रयोगों में आरंभीकरण की गारंटी देगा, तो और भी अधिक कोड होगा ... (आरंभीकरण के दौरान संसाधन को कैप्चर करने और जारी करने के लिए कॉल देखें) नारंगी में रेखांकित है)



इस प्रकार, फर्मवेयर में एक स्थिर चर या ऑब्जेक्ट का उपयोग करने की कीमत रैम आकार और कोड आकार दोनों में बढ़ जाती है। और इस तथ्य को ध्यान में रखना और विकसित करते समय विचार करना अच्छा होगा।

एक और नुकसान यह है कि सुरक्षात्मक ध्वज स्थैतिक चर के साथ एक साथ पैदा होता है, इसका जीवनकाल स्थिर वस्तु के जीवनकाल के बराबर होता है, यह संकलक द्वारा स्वयं बनाया जाता है और विकास के दौरान आपके पास इसका उपयोग नहीं होता है। यानी अगर किसी कारण से अचानक


यदि 1 से ध्वज 0 पर जाता है, तो प्रारंभिक मूल्य के साथ आरंभीकरण फिर से कहा जाता है। यह अच्छा नहीं है, और एक को भी ध्यान में रखना चाहिए। स्थिर चर को संक्षेप में प्रस्तुत करने के लिए:

किसी भी स्थिर ऑब्जेक्ट के लिए (यह एक स्थानीय चर या एक वर्ग विशेषता हो), मेमोरी एक बार आवंटित की जाती है और पूरे एप्लिकेशन में नहीं बदलेगी।

स्थानीय स्थिर चर को पहले चर के माध्यम से घोषित किया जाता है।

स्टेटिक क्लास की विशेषताओं, साथ ही स्थैतिक वैश्विक चर, आवेदन शुरू होने के तुरंत बाद शुरू होते हैं। इसके अलावा, यह आदेश परिभाषित नहीं है

अब वापस सिंगलटन के पास।

सिंगलटन रोम में ऑब्जेक्ट रखता है

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

लेकिन उसके पास एक अद्भुत प्लस है: आप ऑब्जेक्ट के शुरुआती समय को नियंत्रित करते हैं। केवल डेवलपर GetInstance() समय पहली बार GetInstance() को कॉल करता है जब उसे इसकी आवश्यकता होती है।

पहले तीन कमियों से छुटकारा पाने के लिए, यह उपयोग करने के लिए पर्याप्त है


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

इस सिंगलटन को फिर से तैयार किया जा सकता है, ताकि संकलन के समय ऑब्जेक्ट का इनिशियलाइज़ेशन पूरी तरह से स्थिर हो जाए और T ऑब्जेक्ट का एक उदाहरण ROM में static constexpr T instance बजाय static T instance का उपयोग करके बनाया static constexpr T instance :

 template <typename T> class Singleton { public: static constexpr T & GetInstance() { return instance ; } Singleton() = delete ; Singleton(const Singleton<T> &) = delete ; const Singleton<T> & operator=(const Singleton<T> &) = delete ; private: // constexpr  constexpr   //           T static constexpr T instance{T()}; } ; template<typename T> constexpr T Singleton<T>::instance ; 

यहाँ, संकलक द्वारा संकलक स्तर पर ऑब्जेक्ट का निर्माण और आरंभ किया जाएगा और ऑब्जेक्ट .readonly सेगमेंट में गिर जाएगा। सही है, वर्ग को निम्नलिखित नियमों को पूरा करना चाहिए:

• इस वर्ग की किसी वस्तु का आरंभीकरण स्थिर होना चाहिए। (निर्माणकर्ता को विवश होना चाहिए)
• क्लास में एक कॉन्स्ट्रेक्स कॉपी कंस्ट्रक्टर होना चाहिए
• क्लास ऑब्जेक्ट के क्लास मेथड्स में क्लास ऑब्जेक्ट (सभी कास्ट मेथड्स) का डेटा नहीं बदलना चाहिए

उदाहरण के लिए, यह विकल्प काफी संभव है:

 class A { friend class Singleton<A>; public: const A & operator=(const A &) = delete ; int Get() const { return test2.Get(); } void Set(int v) const { test.SetB(v); } private: B& test; //    RAM const C& test2; //    ROM //      constexpr A(const A &) = default ; //     RAM  ROM,  Singleton constexpr A() : test(Singleton<B>::GetInstance()), test2(Singleton<C>::GetInstance()) { } }; int main() { //      ROM auto& myObject = Singleton<A>::GetInstance() ; //           myObject.Set(myObject.Get()) ; cout<<"Singleton<A> - address: "<< &myObject <<std::endl; } 

महान, आप ROM में ऑब्जेक्ट बनाने के लिए सिंगलटन का उपयोग कर सकते हैं, लेकिन क्या होगा अगर कुछ ऑब्जेक्ट रैम में होना चाहिए? जाहिर है, आपको किसी तरह सिंग्लटन के लिए दो विशेषज्ञता रखने की जरूरत है, एक रैम ऑब्जेक्ट्स के लिए, दूसरी रॉम में ऑब्जेक्ट्स के लिए। आप ऐसा कर सकते हैं, उदाहरण के लिए, उन सभी वस्तुओं के लिए जिन्हें ROM बेस क्लास में रखा जाना चाहिए:


इस मामले में, आप उन्हें इस तरह से उपयोग कर सकते हैं:

 //      RAM,   SetB()    (j) class B { friend class Singleton<B>; public: const B & operator=(const B &) = delete ; void SetB(int value) { j = value ; } private: // ,        B(const B &) = default ; B() = default; int j = 0; } //      ROM class A: public RomObject{ friend class Singleton<A>; public: const A & operator=(const A &) = delete ; int Get() const { return test2.Get(); } //     B,    void Set(int v) const { test.SetB(v); } private: B& test; //    RAM const C& test2; //    ROM //        A(const A &) = default ; //     RAM  ROM,  Singleton constexpr A() : test(Singleton<B>::GetInstance()), test2(Singleton<C>::GetInstance()) { } }; int main() { //      ROM auto& romObject = Singleton<A>::GetInstance() ; //    B  RAM auto& ramObject = Singleton<B>::GetInstance() ; //           ramObject.SetB(romObject.Get()) ; cout<<"Singleton<A> - address: "<< &romObject <<std::endl; cout<<"Singleton<B> - address: "<< &ramObject <<std::endl; } 

आप वास्तविक जीवन में इस तरह के सिंगलटन का उपयोग कैसे कर सकते हैं।

सिंगलटन उदाहरण

मैं इसे टाइमर और एलईडी के संचालन के उदाहरण पर दिखाने की कोशिश करूंगा। कार्य सरल है, टाइमर पर एलईडी को ब्लिंक करें। टाइमर सेट किया जा सकता है।

ऑपरेशन का सिद्धांत निम्नानुसार होगा, जब इंटरप्ट कहा जाता है, टाइमर के OnInterrupt() विधि को बुलाया जाएगा, जो बदले में ग्राहक इंटरफ़ेस के माध्यम से एलईडी स्विचिंग विधि को कॉल करेगा।

जाहिर है, एलईडी ऑब्जेक्ट रोम में होना चाहिए, क्योंकि रैम में इसे बनाने का कोई मतलब नहीं है, इसमें डेटा भी नहीं है। सिद्धांत रूप में, मैंने पहले ही इसे ऊपर वर्णित किया है, इसलिए RomObject से विरासत को जोड़ RomObject , एक कॉन्स्ट्रेक्स निर्माता बनाएं और टाइमर से प्रसंस्करण की घटनाओं के लिए इंटरफ़ेस भी इनहेरिट करें।


लेकिन मैं TIM_TypeDef को विशेष रूप से RAM में थोड़ी TIM_TypeDef के साथ TIM_TypeDef हूं, मैं TIM_TypeDef संरचना, एक अवधि और एक ग्राहक के लिंक के लिए एक लिंक स्टोर TIM_TypeDef , और मैं कंस्ट्रक्टर में टाइमर को कॉन्फ़िगर करूंगा (हालांकि टाइमर को ROM पर जाना संभव होगा):

 //       class BlinkTimer: public Timer { friend class Singleton<BlinkTimer> ; public: const BlinkTimer & operator=(const BlinkTimer &) = delete ; private: BlinkTimer(const BlinkTimer &) = default ; inline BlinkTimer(): Timer{*TIM2} { } } ; int main() { BlinkTimer & blinker = Singleton<BlinkTimer>::GetInstance() ; using Led1 = Pin<PortA, 5> ; // Led1,   ROM,      blinker.Subscribe(Singleton<Led1>::GetInstance()) ; blinker.Start() ; } 

इस उदाहरण में, क्लास BlinkTimer की एक वस्तु रैम में स्थित थी, और क्लास Led1 1 की एक वस्तु रोम में स्थित थी। कोड में कोई अतिरिक्त वैश्विक ऑब्जेक्ट नहीं है। उस स्थान पर जहाँ वर्ग उदाहरण की आवश्यकता है, हम बस इस कक्षा के लिए GetInstance() कहते हैं

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

 extern "C" void __iar_program_start(void) ; class InterruptHandler { public: static void DummyHandler() { for(;;) {} } static void Timer2Handler() { //   BlinkTimer Singleton<BlinkTimer>::GetInstance().OnInterrupt(); } }; using tIntFunct = void(*)(); using tIntVectItem = union {tIntFunct __fun; void * __ptr;}; #pragma segment = "CSTACK" #pragma location = ".intvec" const tIntVectItem __vector_table[] = { { .__ptr = __sfe( "CSTACK" ) }, //    __iar_program_start, //      InterruptHandler::DummyHandler, InterruptHandler::DummyHandler, InterruptHandler::DummyHandler, InterruptHandler::DummyHandler, InterruptHandler::DummyHandler, 0, 0, 0, 0, InterruptHandler::DummyHandler, InterruptHandler::DummyHandler, 0, InterruptHandler::DummyHandler, InterruptHandler::DummyHandler, //External Interrupts InterruptHandler::DummyHandler, //Window Watchdog InterruptHandler::DummyHandler, //PVD through EXTI Line detect/EXTI16 .... InterruptHandler::Timer2Handler, //      BlinkTimer InterruptHandler::DummyHandler, //TIM3 ... InterruptHandler::DummyHandler, //SPI 5 global interrupt }; extern "C" void __cmain(void) ; extern "C" __weak void __iar_init_core(void) ; extern "C" __weak void __iar_init_vfp(void) ; #pragma required = __vector_table void __iar_program_start(void) { __iar_init_core() ; __iar_init_vfp() ; __cmain() ; } 

वास्तव में यह सब है, आप कार्यक्रम चला सकते हैं। IAR 8.40 के लिए एक कार्यशील उदाहरण यहाँ है ।
ROM और RAM में ऑब्जेक्ट के लिए सिंगलटन का उपयोग करने का एक अधिक विस्तृत उदाहरण यहां पाया जा सकता है ।

दस्तावेज़ लिंक:

• GOST R mek61508-7-2012
• EWARM के लिए C / C ++ डेवलपमेंट गाइड

PS लेख की शुरुआत में चित्र में, सभी समान, सिंगलटन ROM नहीं है, लेकिन व्हिस्की है।