我需要开发一个Windows / Linux命令行实用程序。该实用程序将与在两个平台上都具有标准API的中间件进行通信。我以前在FreeBSD / Linux上做过一些跨平台开发，这样做要容易得多 - 而且我的团队中有人可以与我交谈。
此时我的小组中没有人处理过Windows / Linux开发项目。我正在寻找有关如何最好地设置它的建议。我也是C ++的新手，我主要开发了C＃/ .Net GUI应用程序和Linux设备驱动程序级别的“东西”。有点奇怪的混合。
我认为最好定义自己的数据类型而不是使用Linux或Windows定义的类型 - 将操作系统特定代码保存在单独的文件夹中并有条件地包含。这就是我们为Linux / BSD工作所做的一切。所以这似乎是一个好的开始。
这里的开发人员之一是Boost的忠实粉丝...另一个想法是TCLAP命令行解析器库更容易使用......显然一切都必须与许可兼容。
代码将是开源的，但它是生产代码 - 所以我不想马虎。我还应该做什么或寻找什么？那里有最好的做法吗？
答案 0 :(得分：5)
Boost很好，ACE也是如此。在其中的两个中，它们涵盖了您希望以跨平台方式执行的任何操作。我也走了获取windows的posix库并在cygwin上使用gcc的路线，但我不推荐它。
答案 1 :(得分：3)
使用两个平台都支持的可移植运行时。我对Apache Portable Runtime祝你好运。
答案 2 :(得分：1)
对大多数项目使用标准C或C ++。仅在必要时才使用平台特定功能。如果可能的话，将它们放在一个包装器中的隔离文件中，以便build（makefile）可以替换为适当平台的正确版本。
避免使用#ifdef LINUX或#ifdef WINDOWS或类似的条件编译。那些变得非常难以调试，并且当关键字未提供给编译器时容易出错。
答案 3 :(得分：1)
使用Boost。除此之外，您将获得TR1子集的可移植实现，如果仅适用于<cstdint>以及 - int32_t内的类型等，这是值得的。同样，shared_ptr是对于许多中等复杂的数据结构至关重要。
Boost还有一些辅助类型，在日常的C ++任务中非常方便。立即浮现在脑海中的两个具体问题是optional和ptr_ ...多种容器类型立即浮现在脑海中。考虑到标准库中缺少非常常用的字符串函数（如大小写转换或修剪），字符串算法库也非常方便。
说到更重量级的组件，Boost.Filesystem是一个非常适合文件系统导航的跨平台抽象，也是命令行工具中相对常见的任务。然后是Boost.MultiIndex是瑞士军刀的容器 - 很少真正需要，但是当它是，它是不可或缺的。
答案 4 :(得分：0)
我今年夏天在.NET上做了一个演出，刚刚移植到Mono。工作得很好。
答案 5 :(得分：0)
虽然有一些很好的跨平台库（如Boost），但请记住它们可能默认不存在。如果您只发送二进制文件，这尤其成问题。目标平台不太可能拥有您需要的库（或库的正确版本）。
一等奖是坚持使用标准C ++（即使你需要自己实现简单的东西）。这完全避免了库的依赖。
如果您必须使用库，请尝试静态链接（尽管这可能会创建大型二进制文件）。这样可以避免由于缺少二进制文件而导致运行时失败。
如果您必须运送DLL（或某些unix上的.so），请确保您的产品附带了正确的版本，并采取某种方式避免与错误版本冲突。
如果要发送代码，请在库中包含代码并构建库以及实用程序。
还要注意GPL和可能的LGPL代码。如果您发布具有GPL依赖关系的库（或修改LGPL库），则需要提供代码并允许根据GPL重新分发。
答案 6 :(得分：0)
TCLAP是我唯一知道的仅限标头的CLI解析选项。因此，它让我觉得最便携，可能是你最好的选择（目前我正在使用并推荐这些原因）。它还有助于TCLAP的API非常适合开发人员，并自动为您生成格式正确的帮助消息。
Boost program_options有一个分片库组件，这对于维护ABI很烦人。它还解决了来自getopt一系列参数的不兼容性和行为的麻烦。
答案 7 :(得分：0)
我使用过libparamset，即跨平台（Windows，OS X，Linux）CLI解析器。它提供了灵活而强大的CLI解析器和各种UI构建功能（输入错误处理，通配符，错字检测，任务解析，帮助格式...），以构建良好的命令行工具。它适用于C和C ++项目。