这是我最喜欢的执行命令行的方式，特别是，但绝对不是只有在效率是一个问题。这可能看起来有点过分，但我认为这种过分有一些缺点。

使用gperf进行高效的C/ c++命令行处理

缺点:

您必须首先运行一个单独的工具来生成C/ c++哈希表的代码 不支持特定的命令行接口。例如，posix简写系统“-xyz”用一个破折号声明多个选项是很难实现的。

优点:

Your command line options are stored separately from your C++ code (in a separate configuration file, which doesn't need to be read at runtime, only at compile time). All you have in your code is exactly one switch (switching on enum values) to figure out which option you have Efficiency is O(n) where n is the number of options on the command line and the number of possible options is irrelevant. The slowest part is possibly the implementation of the switch (sometimes compilers tend to implement them as if else blocks, reducing their efficiency, albeit this is unlikely if you choose contiguous values, see: this article on switch efficiency ) The memory allocated to store the keywords is precisely large enough for the keyword set and no larger. Also works in C

使用像eclipse这样的IDE，您可能可以自动化运行gperf的过程，因此您惟一需要做的就是在配置文件和switch语句中添加一个选项，然后按build…

我使用了一个批处理文件来运行gperf，并做了一些清理，并使用sed添加了包含保护(在gperf生成的.hpp文件上)…

所以，在你的软件中有非常简洁干净的代码和一个自动生成的哈希表文件，你真的不需要手动更改。我怀疑boost::program_options即使没有效率作为优先级，实际上也能打败它。

我建议你去图书馆。有经典而古老的getopt，我相信还有其他的。

提高program_options。

我发现使用ezOptionParser更容易。它也是一个单头文件，只依赖于STL，适用于Windows和Linux(很可能也适用于其他平台)，由于这些示例，它没有学习曲线，具有其他库没有的特性(如带有注释的文件导入/导出、带有分隔符的任意选项名称、自动使用格式等)，并且是LGPL许可的。

尝试Boost::Program Options。它允许您读取和解析命令行以及配置文件。

在c++中，答案通常在Boost中…

提振。程序选项