TCLAP
命令行解析器库更容易使用...显然,所有内容都必须与许可证兼容。代码将会开源,但这是生产代码 - 所以我不想马虎。我还应该做什么或寻找什么?有没有最佳实践可供参考?
TCLAP
命令行解析器库更容易使用...显然,所有内容都必须与许可证兼容。大多数项目使用标准的C或C++。只有在必要时才使用特定于平台的函数。如果可能,将这些函数放在隔离文件中的包装器中,以便构建(makefile)可以替换适当平台的正确版本。
避免使用#ifdef LINUX
或#ifdef WINDOWS
或类似的条件编译。这些很难调试,并且当关键字未提供给编译器时容易出错。
使用Boost。除了其他功能外,您还将获得TR1子集的可移植实现,即使仅为了<cstdint>
和其中的类型-int32_t
等也是值得的。此外,对于许多中等复杂的数据结构,shared_ptr
也是必不可少的。
Boost还具有大量辅助类型,在日常C++任务中非常方便。首先想到的两个特定类型是optional
和ptr_
...立即想到的是多态容器类型。字符串算法库也非常方便,考虑到标准库中缺少非常常见的字符串函数,例如大小写转换或修剪。
说到更重量级的组件,Boost.Filesystem是一个非常不错的跨平台抽象,用于文件系统导航,这也是命令行工具中相对常见的任务。然后,Boost.MultiIndex是容器的瑞士军刀-很少真正需要,但当需要时,它是不可或缺的。
我今年夏天做了一个.NET的项目,现在刚刚转移到了Mono。效果非常好。
虽然有一些很好的跨平台库(如Boost),但请记住它们可能不是默认存在的。 如果您只发布二进制文件,则特别麻烦。 目标平台不太可能拥有您所需要的库(或正确版本的库)。
第一名是坚持使用标准C ++(即使您需要自己实现简单的东西)。 这完全避免了对库的依赖。
如果必须使用库,请尝试静态链接库(尽管这可能会创建大型二进制文件)。 这将使您避免因缺少二进制文件而导致的运行时故障。
如果必须发布DLL(或某些Unix上的.so),请确保正确版本随产品一起发布,并提供一些方式以避免与错误版本发生冲突。
如果您要发布代码,请将库与代码一起包含,并构建库以及您的实用程序。
此外要注意GPL和可能的LGPL代码。 如果您发布具有GPL依赖项(或修改LGPL库)的库,则需要根据GPL提供代码并允许重新分发。
TCLAP
是我所知道的唯一的仅有头文件的CLI解析选项。因此,它给我留下了最具可移植性的印象,很可能是您的最佳选择(这也是我目前使用和推荐的原因)。此外,TCLAP
的API非常开发人员友好,并自动生成适当格式的帮助消息。
Boost program_options
具有共享库组件,这使得维护ABI变得繁琐。它还可以避免来自getopt
参数系列的麻烦解析不兼容性和行为。
我使用了libparamset,它是跨平台(Windows、OS X、Linux)的命令行解析器。它提供了灵活和强大的命令行解析器和各种 UI 构建功能(输入错误处理、通配符、错别字检测、任务解决、帮助格式化等),以构建一个好的命令行工具。它适用于 C 和 C++ 项目。