【问题标题】:Possible to split/cascade getopt_long?可以拆分/级联getopt_long吗?
【发布时间】:2014-06-01 02:08:00
【问题描述】:

我有一个小型 C(不是 C++)应用程序,它使用 getopt_long 解析命令行参数。我想编写另一个应用程序,它共享许多元素(包括一些常见的命令行参数),但也会有一些独特的东西。作为其中的一部分,我想将命令行解析分为通用(在静态库中)和特定于应用程序。

是否可以使用不同的选项集以某种方式级联对getopt_long 的调用,这样如果“外部”调用(特定于应用程序的选项)无法识别选项,它可以尝试调用通用选项解析器,而无需打印除非两者都无法识别该选项,否则会给用户带来任何错误?这必须在逐个选项的基础上完成,因为用户可以按任何顺序传递选项。

我喜欢 getopt 的静态定义常量选项查找表的简单性。我知道我可能可以动态生成一个合并表并只调用一次 getopt 但这似乎更痛苦,我不想这样做。

到目前为止,我对文档的阅读看起来并不乐观。

【问题讨论】:

  • 您是否只想拥有两个使用相同选项的文件?或者你是说让两个不同的文件使用由相同代码定义的不同选项(宏任何人)?
  • 该库将定义两个/所有应用程序通用的选项(例如--verbose--help);这些应用程序将单独定义它们自己独有的选项(例如--do-that-thing-with-the-stuff)。因此,每个应用程序都将支持自己的选项和常用选项。我不想在两个应用程序的代码中复制通用选项,制作库的全部目的是消除重复。我想定义的宏可以工作,我更喜欢动态表构建,但我希望有更优雅的东西。
  • 这只是糟糕的设计。
  • 这取决于你认为什么是好的设计。当您只需编写一个并使用宏来确定要在哪个二进制文件中包含哪些功能时,为什么还要编写两个具有几乎完全相同代码的 .c 文件?
  • 当您可以编写一个 .c 文件进入一个编译到两个应用程序中的静态库时,为什么要这样做呢? (并且根据编译的 .c 文件在头文件中写入具有不同内容的结构将 [a] 违反 OCP,这可能会导致编译时间和多开发人员冲突问题,并且 [b] 如果出现严重的别名问题,你曾经尝试将这些东西构建到同一个应用程序中。)

标签: c linux command-line-arguments getopt


【解决方案1】:

然后我会考虑使用来自 GNU libc 的 argp API。

可以组合 Argp 解析器,请参阅 the example 4。因此,您可以将公共部分放在一个解析器中(在您的共享库中),而将特定于应用程序的解析器放在另一个解析器中。

另外,还可以考虑Glib(来自 GTK,但可独立使用)及其command line option parsing(因为GOptionContext-s 可以包含多个GOptionGroup-s 和g_option_context_add_group ...)

【讨论】:

  • 对不起,直到现在我都错过了这个答案。到目前为止,我一直在使用带有 getopt 的#defines(公共标头提供了COMMON_LONG_OPTSCOMMON_SHORT_OPTS,应用程序必须坚持在正确的位置),但 argp 看起来是一个有趣的替代方案。我会进一步看看。
猜你喜欢
  • 1970-01-01
  • 2010-11-08
  • 1970-01-01
  • 2011-09-10
  • 2018-05-16
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多