问题标签 [portability]

有哪些资源可以帮助编写跨多个平台和编译器工作的 C/C++ 代码？例如，我经常发现自己问这样的问题：

• 在各种编译器和环境中自动定义了哪些预处理器宏？（例如__GCC__, WIN32, __WIN32__, __CYGWIN__）
• 哪些版本的编译器和标准库支持相对较新的“标准”函数（例如 C99 长双三角函数 sinl()、cosl()...）
• 当似乎不存在单一的可移植功能时，不同平台上有哪些功能可用于执行典型任务？（例如以亚秒精度获取当前时间）

我经常编写应该在 Linux/gcc、cygwin、mingw32 和 Visual Studio 下编译的代码，并且我经常需要比较来自多个来源（Linux 手册页、MSDN、编译器文档）的注释以获取我需要的信息。这一定是开发人员一直遇到的问题——是否有任何资源可以将这些信息编译成易于理解的参考？

（对于这个问题，我对 wxWidgets 或 boost 之类的跨平台库并不特别感兴趣。我对可以帮助某人编写自己的跨平台库或程序的资源或技术更感兴趣。）

编辑：这是我正在寻找的页面类型的一个示例：http: //predef.sourceforge.net/precomp.html。对各种编译器/环境以及可用于识别它们的预处理器宏进行了很好的调查。当不存在通用函数时，如果能找到一个类似的资源来比较跨平台的几乎等效函数（如 Linux 中的 gmtime_r() 或 ftime() 与 Windows 中的 _gmtime_s() 或 _ftime()），那就太好了。

概括：

您是否曾经在两个——或者甚至更多——不同的物理工具包之间建立一个接口？对于在线游戏（或至少具有网络物理）？后来如何？得到教训？是在别处重写大量代码更好，还是投资得到了回报？

膨胀：

我正在为我的独立游戏引擎使用ODE 物理工具包，但通过外观包装器。最初的想法是能够在必要时/可能时轻松移植到另一个物理工具包（Havok、Bullet 等）。对于初学者来说，这似乎是一个好主意，但现在它开始看起来像在细节中存在相当多的魔鬼。例如需要单独的每根对象引力（ODE 目前甚至不支持）。或者当对象/岛被禁用时回调（ODE 也不支持）。

Havok（我真的一无所知）随着新工具和工具包的不断发展，这一事实让我担心最终会变成一个框架而不是一个工具包。这对便携性不利，但也许我的担心完全没有根据。

目的

我正在为一个较大的项目编写一个小型库，它提供 malloc/realloc/free 包装函数以及一个函数，该函数可以告诉您其参数（类型void *）是否对应于分配和管理的实时（尚未释放）内存通过库的包装函数。让我们将此函数称为isgood_memory.

在内部，该库维护一个哈希表以确保执行的搜索isgood_memory相当快。哈希表维护指针值（类型的元素void *）以使搜索成为可能。显然，从哈希表中添加和删除值以使其分别与已分配的内容和已释放的内容保持同步。

库的可移植性是我最关心的问题。它被设计成只假设一个最符合 C90 (ISO/IEC 9899:1990) 的环境......仅此而已。

问题

由于可移植性是我最关心的问题，我不能假设sizeof(void *) == sizeof(X)散列函数也是如此。因此，我将值逐字节视为字符串。为此，哈希函数看起来有点像：

你们中的任何人对这个特定片段有什么可移植性问题？ptrval通过逐字节访问，我会遇到任何奇怪的对齐问题吗？

我正在尝试通过静态编译 vim 然后使用我自己的 vimrc 和插件以及生活在我的可移植目录中的东西来使 vim 可移植......

我最近使用了 vi omnicomplete 插件，它说将它安装在 ~/.vim/ 目录中......它工作正常......

但我希望我的便携式vim从恰好是我的vim便携式目录的当前工作目录中找到omnicomplete插件......如果我只是将omnicomplete插件文件夹安装到当前工作目录，这将不起作用......

vim 在 usr/bin 或我的便携式计算机中恰好是从默认的 ~/.vim/ 目录中搜索全能的东西，这是我不想要的，因为我的目标是让它真正可移植..

我可以使用我的自定义 vimrc 和 /usr/share/vim/vim72/plugin 中的所有插件，只需将其复制到我的密码，然后将 VIM 和 VIMRUNTIME env vars 设置为pwd

但是同样的技巧不适用于omnicomplete插件..

非常感谢任何帮助。

谢谢。

我想编写一个库，它将与在现代操作系统（如 Windows、Linux 和 OS/X）上运行的其他程序动态链接（即，它将被部署为一个.dll或.so模块）。

在这种情况下，最合适的语言是什么？我应该坚持使用纯C吗？还是 C++ 也可以？

如果有人在优化代码、实现的清晰性、效率和可移植性方面证明他们的设计权衡是合理的，人们如何选择？

这个问题的相关示例可能是大文件处理，其中“大文件”是“相当几 GB”的问题，可以使用随机访问方法进行简化。

读取和修改此文件的方法可能是：

1. 无论如何都要使用流，并寻找所需的位置 - 这是可移植的，但可能很慢，并且不清楚 - 这几乎适用于所有操作系统。
2. 将文件的相关部分映射为一个大块。例如，为每个块映射一个 50MB 的文件块进行处理 - 这适用于许多操作系统，具体取决于为该系统实现 mmap 的细微之处。
3. 只需 mmap 整个文件 - 这需要 64 位操作系统，是实现此功能的最有效和最清晰的方法，但不适用于 32 位操作系统。

我的公司让我为 Python ORM 完成 Oracle 的后端。我很惊讶 RDBMS 做事情的方式有多么不同，即使是简单的东西。我学到了很多关于 Oracle 和其他 RDBMS 之间差异的知识。纯粹出于好奇，我想了解更多。

在将 SQL 从一个平台移植到另一个平台方面，有哪些常见的“陷阱”？

请，每个答案只有一个陷阱。

是否有用于 C++ 进程管理的知名、可移植、良好的库？

我找到了一个名为Boost.Process的有前途的库，但它只是包含在 Boost 库中的候选库。有人用这个吗？有谁知道为什么它不是Boost的一部分？

我正在尝试使用带有 boost 的 C++ 开发跨平台应用程序。

我通常在 *nix 环境中编程，我总是将“main”定义如下：

对于这个应用程序，我从 Windows 环境开始，使用 Visual Studio 2003。

当我尝试在此定义中使用 boost::program_options 时，我从 program_options::store 中得到编译错误：

错误：

我试图通过如下定义 main 来强制 wchar_t 函数：

然后它编译，但我得到链接错误：

最后，如果我回到 Visual Studio 的默认主定义设置，它会编译并链接：

所以，这对 Windows 来说很好，但是当我尝试将它带到 *nix 时，它会起作用吗？这些系统通常定义 _TCHAR 类型吗？我个人没有遇到过。

定义 main 以在 Windows 和 *nix 上工作以及使用 boost::program_options 库的正确方法是什么？

我想在夏天找点乐子。编写一段代码，可以在支持 Unicode 但不支持东方语言的系统中呈现阿拉伯语。我最初只写逻辑，希望没有集成代码。

我应该使用 C++ 还是 C？

哪种语言更容易编写可移植代码并且更容易与 Python 集成？

编辑：

尽管我认为自己更接近 C++，但我对 C/C++ 相当擅长。但是似乎更容易编写 C 并在每个地方插入它还是我错了？我会编写一些函数来处理阿拉伯语 Unicode 字符串。呈现阿拉伯语需要一些处理，因为几乎所有字符在不同的上下文中都有不同的形状。

编辑：

看来我会使用 C++，只是为了让它更有趣。