विन्यास फाइल। Libconfig पुस्तकालय और अप्रयुक्त सेटिंग्स की परिभाषा

परिचय

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

समस्या

ऐसा हुआ कि हमारी परियोजना के अंदर अधिकांश कॉन्फिडेंस को json और yaml के मिश्रण में लिखा गया और libconfig लाइब्रेरी का उपयोग करके पार्स किया गया। उदाहरण के लिए, यमल पर संबंधित कोड और कॉन्फिग की सामग्री को फिर से लिखने की कोई इच्छा नहीं थी, खासकर जब अन्य दिलचस्प और अधिक जटिल कार्यों का एक गुच्छा हो। और पुस्तकालय का वह हिस्सा जो C में लिखा गया है, अपने आप में अच्छा है: यह स्थिर है और कार्यक्षमता में समृद्ध है (C ++ में सब कुछ इतना सरल नहीं है)।

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

आउटपुट का उपयोग करने के दृष्टिकोण से, हमारे पास निम्नलिखित हैं:

#include <variti/util/config.hpp> #include <iostream> #include <cassert> int main(int argc, char* argv[]) { using namespace variti; using namespace variti::util; assert(argc = 2); config conf( [](const config_setting& st) { if (!st.visited()) std::cerr << "config not visited: " << st.path() << "\n"; }); conf.load(argv[1]); auto root = conf.root(); root["module"]["name"].to_string(); return 0; } 

 laptop :: work/configpp/example ‹master*› % cat config_example1.conf version = "1.0"; module: { name = "module1"; submodules = ( { name = "submodule1"; }, { name = "submodule2"; } ); }; laptop :: work/configpp/example ‹master*› % ./config-example1 config_example1.conf config not visited: root.module.submodules.0.name config not visited: root.module.submodules.1.name 

उदाहरण कोड में, हमने मॉड्यूल.name सेट किया। सेटिंग मॉड्यूल। Submodules.0.name और मॉड्यूल.submodules.1.name एक्सेस नहीं किए गए थे। यह हमें लॉग में बताया गया है।

लपेटना

अगर यह दौरा किया गया झंडा या ऐसा कुछ लागू नहीं होता है तो यह लीबकॉन्फिग के अंदर कैसे है? लाइब्रेरी डेवलपर्स ने पहले से सोचा और config_setting_t नोड को हुक जोड़ने की क्षमता जोड़ी, जो config_setting_set_hook फ़ंक्शन का उपयोग करके सेट किया गया है और config_setting_get_hook का उपयोग करके पढ़ा गया है।

इस हुक को इस प्रकार परिभाषित करें:

 struct config_setting_hook { bool visited{false}; }; 

Libconfig के अंदर दो मुख्य संरचनाएँ हैं: config_t और config_setting_t। पहला एक पूरे के रूप में पूरे कॉन्फिगर को एक्सेस प्रदान करता है और एक पॉइंटर को रूट नोड config_setting_t पर लौटाता है, दूसरा - माता-पिता और बच्चे के नोड्स तक पहुंच, साथ ही साथ वर्तमान नोड के अंदर मूल्य।

हम दोनों संरचनाओं को संबंधित वर्गों में लपेटते हैं - हैंडल।

Config_t के आसपास संभाल:

 using config_notify = std::function<void(const config_setting&)>; struct config : boost::noncopyable { config(config_notify n = nullptr); ~config(); void load(const std::string& filename); config_setting root() const; config_notify n; config_t* h; }; 

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

Config_setting_t के आसपास संभाल:

 struct config_setting : boost::noncopyable { config_setting(config_setting_t* h, bool visit = false); ~config_setting(); bool to_bool() const; std::int32_t to_int32() const; std::int64_t to_int64() const; double to_double() const; std::string to_string() const; bool is_bool() const; bool is_int32() const; bool is_int64() const; bool is_double() const; bool is_string() const; bool is_group() const; bool is_array() const; bool is_list() const; bool is_scalar() const; bool is_root() const; std::string path() const; std::size_t size() const; bool exists(const std::string& name) const; config_setting parent() const; config_setting lookup(const std::string& name, bool visit = false) const; config_setting lookup(std::size_t indx, bool visit = false) const; config_setting operator[](const std::string& name) const; config_setting operator[](std::size_t indx) const; std::string filename() const; std::size_t fileline() const; bool visited() const; config_setting_t* h; }; 

मुख्य जादू देखने के तरीकों में निहित है। यह माना जाता है कि विज़िट किए गए नोड्स ध्वज को अंतिम तर्क के माध्यम से सेट किया जाता है जिसे विज़िट कहा जाता है, जो डिफ़ॉल्ट रूप से गलत है। आपको इस मूल्य को स्वयं इंगित करने का अधिकार है। लेकिन चूंकि नोड्स के लिए सबसे अधिक लगातार पहुंच अभी भी ऑपरेटर [] के माध्यम से है, इसके अंदर लुकअप विधि को सही के बराबर यात्रा के साथ कहा जाता है। इस प्रकार, नोड्स जिसके लिए आप ऑपरेटर कहते हैं [] स्वचालित रूप से चिह्नित के रूप में चिह्नित किया जाएगा। इसके अलावा, जैसा कि दौरा किया गया है, वर्तमान से जड़ तक नोड्स की पूरी श्रृंखला को चिह्नित किया जाएगा।

आइए कार्यान्वयन के लिए आगे बढ़ें। हम इसे पूरी तरह से कॉन्फ़िगर वर्ग के लिए दिखाते हैं:

 config::config(config_notify n) : n(n) { h = (config_t*)malloc(sizeof(config_t)); config_init(h); config_set_destructor(h, [](void* p) { delete reinterpret_cast<config_setting_hook*>(p); }); } config::~config() { if (n) for_each(root(), n); config_destroy(h); free(h); } void config::load(const std::string& filename) { if (!config_read_file(h, filename.c_str())) throw std::runtime_error(std::string("config read file error: ") + filename); } config_setting config::root() const { return config_setting(config_root_setting(h)); } 

और config_setting के लिए आंशिक रूप से:

 config_setting::config_setting(config_setting_t* h, bool visit) : h(h) { assert(h); if (!config_setting_get_hook(h)) hook(h, new config_setting_hook()) if (visit) visit_up(h); } config_setting::~config_setting() { h = nullptr; } std::size_t config_setting::size() const { return config_setting_length(h); } config_setting config_setting::parent() const { return config_setting(config_setting_parent(h)); } bool config_setting::exists(const std::string& name) const { if (!is_group()) return false; return config_setting_get_member(h, name.c_str()); } config_setting config_setting::lookup(const std::string& name, bool visit) const { assert(is_group()); auto p = config_setting_get_member(h, name.c_str()); if (!p) throw_not_found(*this); return config_setting(p, visit); } config_setting config_setting::lookup(std::size_t indx, bool visit) const { assert(is_group() || is_array() || is_list()); auto p = config_setting_get_elem(h, indx); if (!p) throw_not_found(*this); return config_setting(p, visit); } config_setting config_setting::operator[](const std::string& name) const { return lookup(name, true); } config_setting config_setting::operator[](std::size_t indx) const { return lookup(indx, true); } bool config_setting::visited() const { return boost::algorithm::starts_with(path(), "root") || boost::algorithm::starts_with(path(), "root.version") || hook(h)->visited; } 

हुक के साथ काम करने के लिए हम अलग से मदद करने वालों पर विचार करेंगे:

 void hook(config_setting_t* h, config_setting_hook* k) { config_setting_set_hook(h, k); } config_setting_hook* hook(config_setting_t* h) { return reinterpret_cast<config_setting_hook*>(config_setting_get_hook(h)); } void visit_up(config_setting_t* h) { for (; !config_setting_is_root(h) && !hook(h)->visited; h = config_setting_parent(h)) hook(h)->visited = true; } 

और चरम नोड्स को बायपास करने के लिए एक सहायक:

 template <typename F> void for_each(const config_setting& st, F f) { if (st.size()) for (std::size_t i = 0; i < st.size(); ++i) for_each(st.lookup(i), f); else f(st); } 

निष्कर्ष

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

आवेदन

यहाँ स्रोत कोड की जाँच करें !