blocks|key|921943|text|你不会喜欢我的答案的。我用boost::program_options。界面需要一些习惯，但一旦你放下它，它是惊人的。只需确保进行大量单元测试，因为如果语法错误，将获得运行时错误。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|BOLD|entityRanges|data|921944|而且，是的，我将它们存储在一个单例对象(只读)中。我不认为在这种情况下是邪恶的。这是我能想到的少数几个单身人士可以接受的案例之一。|921945|entityMap^0|D|M|29|1|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@$9|L|A|M|B|C]|$9|N|A|O|B|D]]|E|@]|F|$]]|$1|G|3|H|5|6|7|P|8|@]|E|@]|F|$]]|$1|I|3|-4|5|6|7|Q|8|@]|E|@]|F|$]]]|J|$]]

Well, you're not going to like my answer. I use <code>boost::program_options</code>. The interface takes some getting used to, but once you have it down, it's amazing. Just make sure to do boatloads of unit testing, because if you get the syntax wrong you will get runtime errors.

And, yes, I store them in a singleton object (read-only). I don't think it's evil in that case. It's one of the few cases I can think of where a singleton is acceptable.

blocks|key|2306331|text|在谷歌，我们使用旗子。它不做配置文件，但是对于标志，它比使用getopt少得多。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2306332|#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);
++++}
}|code-block|syntax|javascript|2306333|您将DEFINE_foo放在需要知道标志值的文件的顶部。如果其他文件也需要知道值，则在其中使用DECLARE_foo。对于测试也有很好的支持，所以单元测试可以独立地设置不同的标志。|style|CODE|2306334|entityMap|0|LINK|mutability|MUTABLE|url|http://code.google.com/p/google-gflags/^0|8|2|0|0|0|2|A|1B|B|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@$A|V|B|W|1|X]]|C|$]]|$1|D|3|E|5|F|7|Y|8|@]|9|@]|C|$G|H]]|$1|I|3|J|5|6|7|Z|8|@$A|10|B|11|K|L]|$A|12|B|13|K|L]]|9|@]|C|$]]|$1|M|3|-4|5|6|7|14|8|@]|9|@]|C|$]]]|N|$O|$5|P|Q|R|C|$S|T]]]]

At Google, we use <a href="http://code.google.com/p/google-gflags/" rel="noreferrer">gflags</a>. It doesn't do configuration files, but for flags, it's a lot less painful than using getopt.

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

You put the <code>DEFINE_foo</code> at the top of the file that needs to know the value of the flag. If other files also need to know the value, you use <code>DECLARE_foo</code> in them. There's also pretty good support for testing, so unit tests can set different flags independently.

blocks|key|782150|text|对于命令行和C%2B%2B，我一直是TCLAP的粉丝:模板化命令行参数分析器。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|782151|http://sourceforge.net/projects/tclap/|offset|length|782152|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|12|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@$D|O|E|P|1|Q]]|A|$]]|$1|F|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|C]]]]

For command lines and C++, I've been a fan of TCLAP: Templatized Command Line Argument Parser.

<a href="http://sourceforge.net/projects/tclap/" rel="noreferrer">http://sourceforge.net/projects/tclap/</a>

blocks|key|782016|text|如果Boost对你来说太过分了，Gengetopt可能也是，但是IMHO，它是一个有趣的工具来处理。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|782017|而且，我尽量远离全局选项对象，我更喜欢让每个类都读取它自己的配置。除了整个"Globals是邪恶的“哲学，它往往会成为一个不断增长的混乱，让您的所有配置在一个地方，而且很难知道是什么配置变量正在使用的地方。如果您将配置保持在更接近使用它的位置，那么更明显的是每个配置的目的是什么，并且更容易保持干净。|782018|(就我个人而言，最近的每件事都是由我公司的其他人编写的一个专用命令行解析库，但不幸的是，这对你没有多大帮助)|782019|entityMap|0|LINK|mutability|MUTABLE|url|http://www.gnu.org/software/gengetopt/gengetopt.html^0|G|9|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

If Boost is overkill for you, <a href="http://www.gnu.org/software/gengetopt/gengetopt.html" rel="nofollow noreferrer">GNU Gengetopt</a> is probably, too, but IMHO, it's a fun tool to mess around with.

And, I try to stay away from global options objects, I prefer to have each class read its own config. Besides the whole "Globals are evil" philosophy, it tends to end up becoming an ever-growing mess to have all of your configuration in one place, and also it's harder to tell what configuration variables are being used where. If you keep the configuration closer to where it's being used, it's more obvious what each one is for, and easier to keep clean.

(As to what I use, personally, for everything recently it's been a proprietary command line parsing library that somebody else at my company wrote, but that doesn't help you much, unfortunately)

blocks|key|922068|text|我已经使用TCLAP一年或两年了，但我偶然发现了ezOptionParser。ezOptionParser不像其他选项解析器那样受到“它不应该是这么复杂的”-syndrome的困扰。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|922069|到目前为止，我印象非常深刻，而且我可能会继续使用它，特别是因为它支持配置文件。TCLAP是一个更复杂的库，但是来自ezOptionParser的简单性和额外特性非常引人注目。|922070|其网站的其他额外福利包括(截至0.2.0)：|922071|用于调试的解析输入的漂亮打印。|unordered-list-item|922072|在三个布局中创建自动使用消息(对齐、交错或交错)。|922073|单头文件实现。|922074|只依赖STL。|922075|任意短选项名和长选项名(破折号'-‘或加号'%2B’前缀不需要)。|922076|任意参数列表分隔符。|922077|允许多个标志实例。|922078|验证所需选项、每个标志的预期参数数、数据类型范围、用户定义的范围、列表中的成员资格和字符串列表的大小写。|922079|可由字符串或常量定义的验证条件。|922080|带注释的多个文件导入。|922081|导出为文件，可设置选项或所有选项(包括可用时的默认值)。|922082|针对顺序相关上下文的选项解析索引。|922083|entityMap|0|LINK|mutability|MUTABLE|url|http://ezoptionparser.sourceforge.net/^0|O|E|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1E|8|@]|9|@$A|1F|B|1G|1|1H]]|C|$]]|$1|D|3|E|5|6|7|1I|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|1J|8|@]|9|@]|C|$]]|$1|H|3|I|5|J|7|1K|8|@]|9|@]|C|$]]|$1|K|3|L|5|J|7|1L|8|@]|9|@]|C|$]]|$1|M|3|N|5|J|7|1M|8|@]|9|@]|C|$]]|$1|O|3|P|5|J|7|1N|8|@]|9|@]|C|$]]|$1|Q|3|R|5|J|7|1O|8|@]|9|@]|C|$]]|$1|S|3|T|5|J|7|1P|8|@]|9|@]|C|$]]|$1|U|3|V|5|J|7|1Q|8|@]|9|@]|C|$]]|$1|W|3|X|5|J|7|1R|8|@]|9|@]|C|$]]|$1|Y|3|Z|5|J|7|1S|8|@]|9|@]|C|$]]|$1|10|3|11|5|J|7|1T|8|@]|9|@]|C|$]]|$1|12|3|13|5|J|7|1U|8|@]|9|@]|C|$]]|$1|14|3|15|5|J|7|1V|8|@]|9|@]|C|$]]|$1|16|3|-4|5|6|7|1W|8|@]|9|@]|C|$]]]|17|$18|$5|19|1A|1B|C|$1C|1D]]]]

I've been using TCLAP for a year or two now, but randomly I stumbled across <a href="http://ezoptionparser.sourceforge.net/" rel="nofollow">ezOptionParser</a>. ezOptionParser doesn't suffer from "it shouldn't have to be this complex"-syndrome the same way that other option parsers do.

I'm pretty impressed so far and I'll likely be using it going forward, specifically because it supports config files. TCLAP is a more sophisticated library, but the simplicity and extra features from ezOptionParser is very compelling.

Other perks from its website include (as of 0.2.0):

<ul>
<li>Pretty printing of parsed inputs for debugging.</li>
<li>Auto usage message creation in three layouts (aligned, interleaved or staggered).</li>
<li>Single header file implementation.</li>
<li>Dependent only on STL.</li>
<li>Arbitrary short and long option names (dash '-' or plus '+' prefixes not required).</li>
<li>Arbitrary argument list delimiters.</li>
<li>Multiple flag instances allowed.</li>
<li>Validation of required options, number of expected arguments per flag, datatype ranges, user defined ranges, membership in lists and case for string lists.</li>
<li>Validation criteria definable by strings or constants.</li>
<li>Multiple file import with comments.</li>
<li>Exports to file, either set options or all options including defaults when available.</li>
<li>Option parse index for order dependent contexts.</li>
</ul>

blocks|key|2306253|text|getopt很不错。如果您想要一个C%2B%2B感觉，请考虑getoptpp，它是本地getopt的包装器。就配置文件而言，您应该尽量让它变得愚蠢，这样解析就容易了。如果你有点体贴，你可能会想要使用yaac&lex，但对于小型应用程序来说，这真的是一大笔钱。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2306254|我还建议您在应用程序中同时支持配置文件和命令行选项。配置文件更适合那些更改频率较低的选项。当您想要传递立即更改的参数时，命令行选项是很好的(通常是在创建应用程序时，该应用程序将由其他程序调用)。|2306255|entityMap|0|LINK|mutability|MUTABLE|url|http://code.google.com/p/getoptpp/^0|Q|8|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

GNU getopt is pretty nice. If you want a C++ feel, consider <a href="http://code.google.com/p/getoptpp/" rel="nofollow noreferrer">getoptpp</a> which is a wrapper around the native getopt.
As far as configuration file is concerned, you should try to make it as stupid as possible so that parsing is easy. If you are bit considerate, you might want to use yaac&amp;lex but that would be really a big bucks for small apps.

I also would like to suggest that you should support both config files and command line options in your application. Config files are better for those options which are to be changed less frequently. Command-line options are good when you want to pass the immediate changing arguments (typically when you are creating a app, which would be called by some other program.)

blocks|key|922598|text|如果您在x86和x64+Windows上使用Visual+2005，那么SimpleLibPlus库中有一些很好的命令行解析实用程序。我用过它，发现它很有用。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|922599|entityMap|0|LINK|mutability|MUTABLE|url|http://www.toptensoftware.com/simplelib/^0|10|E|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

If you are working with Visual Studio 2005 on x86 and x64 Windows there is some good Command Line Parsing utilities in the <a href="http://www.toptensoftware.com/simplelib/" rel="nofollow noreferrer">SimpleLibPlus library</a>. I have used it and found it very useful.

blocks|key|922517|text|不确定命令行参数解析。在这方面，我不需要非常丰富的功能，而且我通常已经使用自己的功能来节省，为我的软件添加更多的依赖。根据您的需要，您可能想或不想尝试这条路线。我编写的C%2B%2B程序通常不会从命令行调用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|922518|另一方面，对于配置文件来说，您确实无法超过基于XML的格式。它是可读的，可扩展的，结构化的，等等.)此外，还有很多XML解析器存在。尽管它是一个C库，但我倾向于使用来自xmlsoft.org的xmlsoft.org。|922519|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Not sure about command line argument parsing. I have not needed very rich capabilities in that area and have generally rolled my own to save adding more dependencies to my software. Depending upon what your needs are you may or may not want to try this route. The C++ programs I have written are generally not invoked from the command line.

On the other hand, for a config file you really can't beat an XML based format. It's readable, extensible, structured, etc... :) Plus there are lots of XML parsers out there. Despite the fact it is a C library, I tend to use libxml2 from xmlsoft.org.

blocks|key|922494|text|试试Apache+Ant。它的主要用途是Java项目，但是它没有任何Java，而且它几乎可以用于任何东西。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|922495|使用非常简单，您也得到了很多社区支持。它非常擅长按你要求的方式做事。|922496|至于代码中的全局选项，我认为它们是非常必要和有用的。不过，别滥用它们。|922497|entityMap|0|LINK|mutability|MUTABLE|url|http://ant.apache.org/^0|2|A|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

Try <a href="http://ant.apache.org/" rel="nofollow noreferrer">Apache Ant</a>. Its primary usage is Java projects, but there isn't anything Java about it, and its usable for almost anything. 

Usage is fairly simple and you've got a lot of community support too. It's really good at doing things the way you're asking.

As for global options in code, I think they're quite necessary and useful. Don't misuse them, though.

What packages do you use to handle command line options, settings and config files? 

I'm looking for something that reads user-defined options from the command line and/or from config files. 

The options (settings) should be dividable into different groups, so that I can pass different (subsets of) options to different objects in my code.

I know of <code>boost::program_options</code>, but I can't quite get used to the <code>API</code>. Are there light-weight alternatives?

(BTW, do you ever use a global options object in your code that can be read from anywhere? Or would you consider that evil?)

How do you handle command line options and config files?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

您使用哪些包来处理命令行选项、设置和配置文件？我正在寻找从命令行和/或配置文件中读取用户定义选项的内容。选项(设置)应该被划分成不同的组，这样我就可以在代码中将不同的(子集)选项传递给不同的对象。我知道boost::program_options，但我不太习惯API。有轻量化的替代品吗？(顺便说一句，您是否曾在代码中使用可以从任何地方读取的全局选项对象？或者你会认为这是邪恶的？)

问如何处理命令行选项和配置文件？
EN

回答 9

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何处理命令行选项和配置文件？EN

回答 9

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何处理命令行选项和配置文件？
EN