11

कमांड लाइन विकल्प, सेटिंग्स और कॉन्फ़िगरेशन फ़ाइलों को संभालने के लिए आप किस पैकेज का उपयोग करते हैं?आप कमांड लाइन विकल्प और कॉन्फ़िगरेशन फ़ाइलों को कैसे प्रबंधित करते हैं?

मैं कुछ ऐसी चीज ढूंढ रहा हूं जो उपयोगकर्ता परिभाषित विकल्प कमांड लाइन और/या कॉन्फ़िगरेशन फ़ाइलों से पढ़ता है।

विकल्प (सेटिंग्स) अलग-अलग समूहों में विभाजित होना चाहिए, ताकि मैं अपने कोड में अलग-अलग ऑब्जेक्ट्स के अलग-अलग (सबसेट्स) विकल्प पास कर सकूं।

मैं boost::program_options के बारे में पता है, लेकिन मैं काफी API के लिए नहीं किया जा सकता। क्या हल्के वजन वाले विकल्प हैं?

(btw, क्या तुमने कभी का उपयोग एक वैश्विक विकल्प आपके कोड है कि कहीं से भी पढ़ा जा सकता है में आपत्ति? या आप है कि बुराई पर विचार करेंगे? देखें)

उत्तर

5

ठीक है, आप मेरे जवाब को पसंद नहीं करेंगे। मैं boost::program_options का उपयोग करता हूं। इंटरफ़ेस कुछ उपयोग करने के लिए लेता है, लेकिन एक बार जब आप इसे नीचे ले जाते हैं, तो यह आश्चर्यजनक है। बस यूनिट परीक्षण के बोतलबंद करना सुनिश्चित करें, क्योंकि अगर आपको वाक्यविन्यास गलत लगता है तो आप रनटाइम त्रुटियां प्राप्त करेंगे।

और, हाँ, मैं उन्हें एक सिंगलटन ऑब्जेक्ट में संग्रहित करता हूं (केवल पढ़ने के लिए)। मुझे नहीं लगता कि यह उस मामले में बुराई है। यह उन कुछ मामलों में से एक है जहां मैं सोच सकता हूं कि सिंगलटन स्वीकार्य है।

+1

+1 :: program_options, लेकिन केवल बस! मैं सिंगलटन के रूप में प्रोग्राम विकल्पों का उपयोग करने से सावधान रहूंगा। हमें ऐसा करके काट दिया गया है कि अब हमें विभिन्न फाइलों के लिए विकल्पों के विभिन्न सेट जोड़ने की जरूरत है। हमें पहले वापस जाने और सिंगलटन को हटाने की आवश्यकता है ताकि हम प्रत्येक व्यक्तिगत फ़ाइलों के लिए विकल्पों के विभिन्न सेट स्टोर कर सकें। –

+0

अच्छा बिंदु, रिचर्ड। मैं एक गेम के लिए boost :: program_options का उपयोग करता हूं, और स्पष्ट रूप से विकल्पों का 1 सेट प्रति प्रक्रिया पर्याप्त है, लेकिन विभिन्न उद्देश्यों के लिए यह एक बुरा विचार होगा। – rlbond

+0

क्या आप अभी भी boost :: program_options के पक्ष में हैं? ऐसा लगता है कि अब विकसित नहीं हुआ है (दस्तावेज़ वेब साइट को अंतिम बार संशोधित किया गया था)। क्या यह सी ++ 11 के साथ उपयोग/अनुकूल है? अपनी पोस्ट की लाइनों के बीच पढ़ते समय, यह वास्तव में एक अच्छी सिफारिश नहीं है: * बस यूनिट परीक्षण के बोतलबंद करना सुनिश्चित करें, क्योंकि अगर आपको वाक्यविन्यास गलत लगता है तो आपको रनटाइम त्रुटियां मिलेंगी * एक बड़ा लाल झंडा है! – Walter

-4

Apache Ant की कोशिश करो। इसका प्राथमिक उपयोग जावा प्रोजेक्ट है, लेकिन इसके बारे में जावा कुछ भी नहीं है, और यह लगभग किसी भी चीज़ के लिए उपयोग योग्य है।

उपयोग काफी सरल है और आपके पास बहुत सा समुदाय समर्थन भी है। जिस तरह से आप पूछ रहे हैं, वही करने में वाकई अच्छा है।

कोड में वैश्विक विकल्पों के लिए, मुझे लगता है कि वे काफी आवश्यक और उपयोगी हैं। हालांकि, उनका दुरुपयोग मत करो।

+3

उह, अपाचे चींटी? निर्माण उपकरण? सी ++ में कमांड लाइन विकल्पों को पढ़ने के साथ क्या करना है? – Frank

+0

आप सी ++ के लिए मूल कॉन्फ़िगरेशन फ़ाइल रख सकते हैं, लेकिन सभी वास्तविक कार्य चींटी के साथ किया जा सकता है। Http://www.codemesh.com/products/junction/doc/ant_cpp.html या बस http://www.google.com/search?hl=hi&site=&q=using+ant+c%2B%2B&btnG= देखें खोज –

0

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

दूसरी ओर, कॉन्फ़िगरेशन फ़ाइल के लिए आप वास्तव में एक XML आधारित प्रारूप को हरा नहीं सकते हैं। यह पठनीय, एक्स्टेंसिबल, संरचित, आदि है ... :) इसके अलावा वहां बहुत सारे एक्सएमएल पार्सर्स हैं। इस तथ्य के बावजूद यह एक सी पुस्तकालय है, मैं xmlsoft.org से libxml2 का उपयोग करता हूं।

+0

सी ++ में लिखे गए एक तेज एक्सएमएल पार्सर्स के लिए [pugixml.org] (http://pugixml.org) देखें। बोनस के रूप में, यह 'XPath' का समर्थन करता है और केवल हेडर भी है! बढ़ावा देने के लिए – Sean

3

यदि बूस्ट आपके लिए अधिक है, तो GNU Gengetopt शायद भी है, लेकिन IMHO, यह एक मजेदार टूल है जिसके साथ गड़बड़ है।

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

(के रूप में करने के लिए कि मैं क्या उपयोग करते हैं, व्यक्तिगत रूप से, हाल ही में सब कुछ के लिए यह एक मालिकाना कमांड लाइन को पार्स पुस्तकालय है कि मेरी कंपनी में किसी और ने लिखा है, लेकिन इतना तुम मदद नहीं करता है, दुर्भाग्य से)

1

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

मैं यह भी सुझाव देना चाहता हूं कि आपको अपने आवेदन में कॉन्फ़िगरेशन फ़ाइलों और कमांड लाइन विकल्पों दोनों का समर्थन करना चाहिए। कॉन्फ़िगरेशन फ़ाइलें उन विकल्पों के लिए बेहतर होती हैं जिन्हें कम बार बदला जाना है। कमांड लाइन विकल्प अच्छे होते हैं जब आप तत्काल बदलते तर्कों को पारित करना चाहते हैं (आमतौर पर जब आप एक ऐप बना रहे हैं, जिसे किसी अन्य प्रोग्राम द्वारा बुलाया जाएगा।)

11

Google पर, हम gflags का उपयोग करते हैं। यह विन्यास फाइल नहीं करता है, लेकिन झंडे के लिए, यह getopt का उपयोग करने से बहुत कम दर्दनाक है।

#include <gflags/gflags.h> 
DEFINE_string(server, "foo", "What server to connect to"); 
int main(int argc, char* argv[]) { 
    google::ParseCommandLineFlags(&argc, &argv, true); 
    if (!server.empty()) { 
     Connect(server); 
    } 
} 

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

+0

मुझे पसंद है! उपयोग करने के लिए बहुत आसान लग रहा है। – Milan

1

यदि आप x86 और x64 विंडोज पर विजुअल स्टूडियो 2005 के साथ काम कर रहे हैं तो SimpleLibPlus library में कुछ अच्छी कमांड लाइन पार्सिंग सुविधाएं हैं। मैंने इसका इस्तेमाल किया है और इसे बहुत उपयोगी पाया है।

6

कमांड लाइनों और सी ++ के लिए, मैं टीसीएलएपी का प्रशंसक रहा हूं: टेम्पलेटलाइज्ड कमांड लाइन आर्ग्यूमेंट पार्सर।

http://sourceforge.net/projects/tclap/

3

मैं एक या दो साल के लिए अब TCLAP का उपयोग किया गया है, लेकिन बेतरतीब ढंग से मैं ezOptionParser भर में ठोकर खाई। ezOptionParser "यह जटिल नहीं होना चाहिए" से पीड़ित नहीं है- सिंड्रोम उसी तरह से अन्य विकल्प पार्सर्स करते हैं।

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

ने अपनी वेबसाइट से अन्य भत्ते (0.2.0) के रूप में शामिल हैं:

  • डिबगिंग के लिए पार्स आदानों की सुंदर मुद्रण।
  • तीन लेआउट (गठबंधन, interleaved या staggered) में ऑटो उपयोग संदेश निर्माण।
  • सिंगल हेडर फ़ाइल कार्यान्वयन।
  • केवल एसटीएल पर आश्रित।
  • मनमाना लघु और लंबा विकल्प नाम (डैश '-' या प्लस '+' उपसर्ग आवश्यक नहीं है)।
  • मनमाने ढंग से तर्क सूची delimiters।
  • एकाधिक ध्वज उदाहरणों की अनुमति है।
  • आवश्यक विकल्पों का सत्यापन, प्रति ध्वज अपेक्षित तर्कों की संख्या, डेटाटाइप श्रेणियां, उपयोगकर्ता परिभाषित श्रेणियां, सूचियों में सदस्यता और स्ट्रिंग सूचियों के मामले।
  • स्ट्रिंग या स्थिरांक द्वारा निर्धारित सत्यापन मानदंड।
  • टिप्पणियों के साथ एकाधिक फ़ाइल आयात।
  • फ़ाइल करने के लिए निर्यात, या तो विकल्प सेट करें या उपलब्ध होने पर डिफ़ॉल्ट सहित सभी विकल्प।
  • ऑर्डर पर निर्भर संदर्भों के लिए विकल्प पार्स इंडेक्स।
+0

मुझे पता है कि यह एक बहुत पुराना धागा है, लेकिन इस थ्रेड को पढ़ने के बाद, मैंने जो भी किया है, उसी तरह किसी भी जाल में गिरने से बचने के लिए। ezOptionParser वास्तव में पार्सिंग विकल्पों के लिए अच्छी तरह से काम करता है, लेकिन इसमें एक घातक बग है जो आपके अनुप्रयोग को क्रैश करता है यदि आप getUsage() फ़ंक्शन का उपयोग कमांड लाइन विकल्पों की रिपोर्ट करने के लिए करते हैं। पुस्तकालय अब लेखक द्वारा समर्थित नहीं है, इसलिए यह बग कभी तय नहीं किया जाएगा। अत्यधिक सावधानी के साथ प्रयोग करें; या बेहतर, कुछ और उपयोग करें। – Graham

संबंधित मुद्दे