हम एक उपयोगी थ्रेड-आधारित लॉग लागू करते हैं

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

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

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

दूसरा कारण बहुत अधिक पेशेवर है। Trifles करने के लिए आनाकानी। विशेष रूप से परियोजना की शुरुआत में। और टीम जितनी छोटी होगी, प्रभाव उतना ही अधिक होगा। बेशक, मल्टीमिथोड्स [1] का उपयोग करने की संभावनाओं पर चर्चा करना अधिक दिलचस्प है ताकि यह सुनिश्चित हो सके कि ऑपरेटर रिक्त स्थान से अलग हो रहे हैं। और इस तरह के trifles का अंतिम कार्यक्षमता से कोई विशेष संबंध नहीं है। क्या पहले प्राथमिक आवश्यकताओं पर ध्यान केंद्रित करना बेहतर नहीं है, क्योंकि परियोजना का समय और बजट सीमित है ...

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

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

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

• पूर्ण इंटरफ़ेस
• क्रॉस-प्लेटफॉर्म
• आईडीई कंसोल में संदेश प्रदर्शित करना
• सुविधा और उपयोग में आसानी
• डेवलपर उपकरण

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

अक्सर एक हफ्ते के बाद आप अपने कोड को देखते हैं जैसे कि वह किसी और का हो। यह स्पष्ट है कि कई महीनों के बाद, कार्यान्वयन की कई बारीकियों (विशेष रूप से, एक महत्वपूर्ण समस्या क्या है, और क्या सिर्फ एक मामूली आकस्मिकता है) हमेशा के लिए खो जाएगी।

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

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

क्योंकि उपयोगकर्ता इंटरफ़ेस कार्यक्षमता के लिए बहुत देर हो सकती है - यह सब समय डेवलपर्स "अपने रस में पकाना" होगा। एक बड़ा अंतर है, आपने इसे बनाने के कुछ सेकंड या हफ्तों बाद समस्या को देखा।

सुविधा और उपयोग में आसानी। प्रोग्रामर एक आलसी प्राणी है। मान लीजिए कि आप किसी समस्या की रिपोर्ट करना चाहते हैं: आकार की एक छवि 100 से 120 प्राप्त की जाती है, जबकि वर्तमान एप्लिकेशन सेटिंग्स 128 के न्यूनतम आकार पर 128 तक एक सीमा निर्धारित करती हैं। यदि आप केवल एक सरल रेखा का उत्पादन कर सकते हैं, तो डेवलपर को एक पर्याप्त आउटपुट तैयार करना होगा।

1. स्ट्रिंग प्रकार के लिए चार नंबर डाले
2. प्राप्त भागों से एक रेखा बनाते हैं
3. लॉग करने के लिए एक लाइन पास करें

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

इसलिए, लॉगिंग सबसिस्टम को आउटपुट स्ट्रिंग्स के सुविधाजनक स्वरूपण के लिए उपकरण प्रदान करना चाहिए, डेवलपर को मूल बुनियादी प्रकारों को स्ट्रिंग करने के लिए मजबूर किए बिना। यहाँ C ++ में दो दिशाएँ संभव हैं।

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

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

डेवलपर का ध्यान आकर्षित करने के साधन। प्रोग्रामर व्यस्त है। यह आईडीई आउटपुट कंसोल में भी त्रुटि नहीं देख सकता है। समस्या आसानी से सूचना संदेशों के बादलों के बीच खो सकती है। इसलिए, सबसे पहले, लॉग को आउटपुट स्तर सेटिंग का समर्थन करना चाहिए। उदाहरण के लिए, "केवल त्रुटियों और चेतावनियों को प्रदर्शित करें।" यह आवश्यक है, लेकिन यह पर्याप्त नहीं है - प्रदर्शन करने के लिए समय-समय पर ट्यूनिंग की आवश्यकता होती है। और प्रोग्रामर व्यस्त है।

यहां विशेष मुखर मैक्रो [4] आता है। यह आपको किसी समस्या के स्थान पर एक कार्यक्रम के निष्पादन को बाधित करने की अनुमति देता है। परिणाम अलग है - विज़ुअल स्टूडियो विंडो प्रदर्शित होने और एक डरावनी आवाज़ के बाद निष्पादन जारी रखना संभव बनाता है, Xcode ध्वनियों के साथ आवाज़ को डराता नहीं है, लेकिन निष्पादन को जारी रखने की भी अनुमति नहीं देता है। सामान्य तौर पर, ध्यान की गारंटी है। इस मामले में, डायग्नोस्टिक संदेश खुद आईडीई आउटपुट कंसोल के अंत में कंसोल के अंत में दिखाई देगा, अक्सर स्टॉप के कारण की तलाश में कॉल स्टैक को देखने की आवश्यकता को पूरी तरह से समाप्त कर देता है।


चित्रा 1. एक चेतावनी पर एक कार्यक्रम का व्यवधान

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

सबसे पहले, लॉगिंग क्लास के मूल इंटरफ़ेस को देखें।

class Log { public: 

सबसे पहले, हम लॉग विवरण के चार स्तरों (घोषणा के क्रम में) का परिचय देते हैं:

1. किसी लॉग का पूर्ण शटडाउन
2. आउटपुट केवल त्रुटियाँ हैं
3. चेतावनी और त्रुटियाँ प्रदर्शित करें
4. सभी प्रकार के संदेशों का आउटपुट

  enum DebugLevel { DEBUG_LEVEL_DISABLED = 0, DEBUG_LEVEL_ERROR = 1, DEBUG_LEVEL_WARNING = 2, DEBUG_LEVEL_MESSAGE = 3, }; 

तदनुसार, हम मान्य प्रकारों के तीन और पहचानकर्ताओं को जोड़ते हैं: सूचनात्मक संदेश, चेतावनी और त्रुटि।

  enum MessageType { MESSAGE_INFO, MESSAGE_WARNING, MESSAGE_ERROR, }; 

निम्न विधि एक वर्ग को तत्काल करने के लिए है। निर्माण क्षेत्र को संरक्षित क्षेत्र में रखने से प्रत्यक्ष निर्माण निषिद्ध है।

 static void createInstance(); 

अंतिम उपलब्ध सार्वजनिक विधि लॉग के विवरण के स्तर को निर्धारित करने के लिए डिज़ाइन की गई है। बाकी सब बंद हो रहा है। यह एक प्रारंभिक लॉग इंटरफ़ेस है - भविष्य में यह दिखाया जाएगा कि यह वास्तव में संदेश प्रदर्शित करने के लिए कैसा है।

  void setDebugLevel(DebugLevel level); protected: 

संरक्षित क्षेत्र का वादा निजी निर्माणकर्ता द्वारा किया जाता है।

  Log(); 

एकमात्र शुद्ध आभासी विधि IDE कंसोल के लिए प्लेटफ़ॉर्म-निर्भर जानकारी आउटपुट के लिए डिज़ाइन की गई है

  virtual void writeIDEDebugString(const std::string& message, MessageType type) = 0; private: 

निम्न तीन विधियाँ प्रत्येक प्रकार के अलर्ट को सीधे आउटपुट देने का काम करेंगी। प्रोग्रामर को गलती से उपयोग करने से रोकने के लिए, वे कक्षा के एक निजी क्षेत्र में छिपे हुए हैं।

  void writeMessage(const std::string& message); void writeWarning(const std::string& message); void writeError(const std::string& message); 

फ़ाइल के लिए उत्पादन विधि। यहां इसका कार्यान्वयन नहीं दिया जाएगा, क्योंकि इसका लेख के विषय से कोई सीधा संबंध नहीं है।

  void appendToFile(const std::string& message); 

खैर, आपको डिबग संदेश बनाने के लिए एक उपयोगिता फ़ंक्शन की आवश्यकता होगी। आमतौर पर, प्रत्येक संदेश में एक समय टिकट और लाइन के महत्व के स्तर का संकेत जोड़ा जाता है।

  void writeMessage(const std::string& message, MessageType type); 

वर्ग डेटा से, हमें लॉग के विस्तार और उसके उदाहरण के स्तर को संग्रहीत करने की आवश्यकता है।

  DebugLevel mDebugLevel; static Log* sInstance; }; 

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

 void Log::writeError(const std::string& message) { if (mDebugLevel >= DEBUG_LEVEL_ERROR) { writeMessage(getLogString(message, "error"), MESSAGE_ERROR); } #ifdef _DEBUG assert(0); #endif exit(EXIT_FAILURE); } 

तो, सबसे पहले, यह जाँच की जाती है कि विस्तार का स्तर त्रुटि आउटपुट के लिए अनुमति देता है, फिर राइटमैसेज उपयोगिता पद्धति को कहा जाता है, जिससे संदेश और संदेश प्रकार प्रेषित होता है। परिणाम कुछ इस तरह होगा
त्रुटि: [संदेश]

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

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

बदले में, राइटमैसेज इस प्रकार है

 void Log::writeMessage(const std::string& message, MessageType type) { std::string text(message); std::replace(text.begin(), text.end(), '\n', ' '); appendToFile(text); #ifdef _DEBUG writeIDEDebugString(text, type); #endif } 

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

डीबग मोड _DEBUG मैक्रो द्वारा निर्धारित किया जाता है, जिसे आमतौर पर विज़ुअल स्टूडियो में स्वचालित रूप से पता लगाया जाता है। अन्य विकास के वातावरण में, सबसे अधिक संभावना है, इसे मैन्युअल रूप से जोड़ना होगा। किसी भी मामले में, यह किसी विशेष कठिनाइयों का कारण नहीं बनता है।


चित्र 2. Xcode के लिए डीबग मैक्रो विशेषता परिभाषाएँ

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

विंडोज (विजुअल स्टूडियो)

 void Log_Windows::writeIDEDebugString(const std::string& message, MessageType type) { OutputDebugStringA(message.c_str()); OutputDebugStringA("\n"); } 

Android (ग्रहण)

void Log_Android :: writeIDEDEDugugString (const स्ट्रिंग और संदेश, MessageType प्रकार)

 { switch(type){ case MESSAGE_INFO: __android_log_print(ANDROID_LOG_INFO, "", message.c_str()); break; case MESSAGE_WARNING: __android_log_print(ANDROID_LOG_WARN, "", message.c_str()); break; case MESSAGE_ERROR: __android_log_print(ANDROID_LOG_ERROR, "", message.c_str()); break; } } 

जैसा कि आप देख सकते हैं, एंड्रॉइड के मामले में हमें अतिरिक्त स्पष्टता मिलती है: विभिन्न रंगों में संदेश प्रदर्शित करना संभव है। लाल रंग में प्रदर्शित होने वाली समस्या को ध्यान दिए बिना भागने की बहुत कम संभावना होती है, यहां तक ​​कि बिना जोर लगाए भी।


चित्रा 3. ग्रहण में टाइप के आधार पर रंग संदेश

MacOS और iOS (Xcode)

 void Log_Mac::writeIDEDebugString(const std::string& message, MessageType type) { NSLog(@"%s", message.c_str()); } 

हमने एक प्रत्यक्ष निष्कर्ष निकाला, सवाल यह है कि इसे धाराओं में कैसे ठीक से पैक किया जाए। आखिरकार, हमने सभी निकासी के तरीके बंद कर दिए हैं।

पहले, वांछित प्रविष्टि के बारे में फैसला करते हैं। C ++ स्ट्रीम आउटपुट पैरामीटर उसी तरह प्राप्त कर सकते हैं जिस तरह से डेटा उनके पास जाता है। उदाहरण के लिए, संदेश बड़े अक्षरों में प्रदर्शित किया जाएगा।

 std::cout << std::uppercase << "test" << '\n'; 

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

 Log::error<<"text"<<std::endl; Log::warning<<"text"<<std::endl; Log::message<<"text"<<std::endl; 

यानी संदेश के प्रकार के बारे में जानकारी स्ट्रीम ऑब्जेक्ट में ही होगी। बेशक, स्टैड :: अपरकेस जैसी मानक स्ट्रीम पैरामीटर अभी भी उपयोग किए जा सकते हैं। सभी स्ट्रीम कार्यक्षमता मानक लाइब्रेरी कक्षाओं से विरासत में मिली है।

 class Streamer : public std::ostream { public: Streamer(MessageType messageType); ~Streamer(); private: class StringBuffer : public std::stringbuf { public: Buffer(MessageType messageType); ~Buffer(); virtual int sync(); private: MessageType mMessageType; }; }; 

प्रत्येक प्रकार की स्ट्रीम में अपनी स्वयं की वस्तु होगी, इसलिए निर्माता मैसेज टाइप पैरामीटर को स्वीकार करते हैं। आउटपुट क्लास में ही हमें std :: ostream [5] विरासत में मिला है, नेस्टेड क्लास StringBuffer स्ट्रिंग बनाने के लिए जिम्मेदार होगा, जो बदले में std :: stringbuf [6] से विरासत में मिलेगा। हर बार जब उपयोगकर्ता संदेश के गठन को पूरा करने की घोषणा करता है, तो सिंक विधि को स्वचालित रूप से कॉल किया जाएगा, जिसमें हम प्रत्यक्ष आउटपुट निष्पादित करेंगे। आप बफर धाराओं के लिए मानक विधियों का उपयोग करके आउटपुट के पूरा होने की रिपोर्ट कर सकते हैं: फ्लश विधि को कॉल करके

 Log::message<<"text"; Log::message.flush(); 

या सिर्फ std :: endl को स्ट्रीम में जोड़ना

 Log::message<<"text"<<std::endl; 

आपको एक स्ट्रिंग बफर के साथ आउटपुट स्ट्रीम को संबद्ध करने की भी आवश्यकता है। यह कंस्ट्रक्टर में किया जाता है।

 Log::Streamer::Streamer(Log::MessageType messageType) : std::ostream(new StringBuffer(messageType)) { } 

तदनुसार, विनाश होने पर, बफर को अपने आप नष्ट हो जाना चाहिए।

 Log::Streamer::~Streamer() { delete rdbuf(); } 

बफर कंस्ट्रक्टर में, प्रदर्शित संदेश के प्रकार को याद रखना पर्याप्त है

 Log::Streamer::StringBuffer:: StringBuffer(Log::MessageType messageType) : mMessageType(messageType) { } 

जब नष्ट हो जाता है, बस के मामले में, हम इसके सिंक्रनाइज़ेशन का कारण बनते हैं - यह संदेश "गायब" होने से रोकेगा यदि प्रोग्रामर फ्लश या एंडल कॉल करना भूल जाता है।

 Log::Streamer::Buffer::~Buffer() { pubsync(); } 

ताकि स्ट्रीम में लॉग क्लास के मुख्य इंटरफ़ेस तक पहुंच हो, जो बाहरी दुनिया के लिए बंद है, हम इसे अंदर डालते हैं

 class Log { public: ... class Streamer : public std::ostream { ... }; static Streamer message; static Streamer warning; static Streamer error; ... 

संदेश चेतावनी और त्रुटि प्रत्येक प्रकार के संदेश के लिए थ्रेड इंस्टेंस हैं। कंस्ट्रक्टर में संदेश का प्रकार उनके पास गया

 Log::Streamer Log::message(Log::MESSAGE_INFO); Log::Streamer Log::warning(Log::MESSAGE_WARNING); Log::Streamer Log::error(Log::MESSAGE_ERROR); 

और अंत में, स्ट्रीम स्ट्रिंग बफर सिंक्रोनाइज़ेशन फ़ंक्शन के कार्यान्वयन पर विचार करें।

 int Log::Streamer::StringBuffer::sync() { if (Log::sInstance == NULL) { return 0; } std::string text(str()); if (text.empty()) { return 0; } str(""); switch (mMessageType) { case MESSAGE_INFO: Log::sInstance->writeMessage(text); break; case MESSAGE_WARNING: Log::sInstance->writeWarning(text); break; case MESSAGE_ERROR: Log::sInstance->writeError(text); break; } return 0; } 

नेस्टेड क्लास लॉग के रूप में :: स्टीमर :: बफ़र की लॉग के एक निजी (निजी) क्षेत्र में पहुँच है। केवल str () फ़ंक्शन को स्पष्टीकरण की आवश्यकता है। यह std :: stringbuf वर्ग की एक अजीब विधि है, जो एक ही समय में आपको बफर मान प्राप्त करने और सेट करने की अनुमति देता है। इसके दोनों रूपों में इसका उपयोग किया जाता है - पहला, इस फ़ंक्शन का उपयोग करके, हमें बफर से एक स्ट्रिंग मिलती है, और फिर str ("") को कॉल करके हम बफर को साफ करते हैं।
यही है, अब स्टीमर वर्ग लॉग का "आधिकारिक" इंटरफ़ेस बन गया है। समग्र संदेश प्रदर्शित करने के लिए "i (6) की सीमा [1..5] होनी चाहिए", यह प्रोग्रामर के लिखने के लिए पर्याप्त है

 Log::warning << "i (" << i << ") should be in range [" << I_MIN << ".." << I_MAX << "]" << std::endl; 

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

[१] en.wikipedia.org/wiki/Multiple_dispatch
[२] www.cplusplus.com/reference/cstdio/sprintf
[३] www.cplusplus.com/reference/sstream/stringstream
[४] www.cplusplus.com/reference/cassert/assert
[५] www.cplusplus.com/reference/ostream/ostream
[६] www.cplusplus.com/reference/sstream/stringbuf