跨平台代码的3种组织方式

上一篇文章中，分享了一个跨平台的头文件是长成什么样子的，这个头文件对于 windows 平台下更有意义一些，因为要处理库函数的导入和导出声明(dllexport、dllimport)。

其实，可以在这个头文件的基础上继续扩充，以达到更细粒度的控制。例如：对编译器的判断、对编译器版本的判断等等。

同样的，我们在源代码中也会遇到一些跨平台的问题。不同的功能，在不同的平台下，实现方式是不一样的，如何对这些平台相关的代码进行组织呢?这篇文章就来聊聊这个问题。

PS: 文末提供了一个简单的、跨平台构建代码示例。

二、问题引入

假设我们写一个库，需要实现一个函数：获取系统时间戳。作为实现库的作者，你决定提供下面的 API 函数：么问题来了：怎么把这两段平台相关的代码组织在一起?下面就介绍 3 种不同的组织方式，没有优劣之分，每个人都有不同的习惯，选择适合自己和团队的方式就行。

此外，这个示例中只有 1 个函数，而且比较短小。如果这种跨平台的函数很多、而且都很长，也许你的选择又不一样了。

三、三个解决方案

方案1

直接在接口函数中，通过平台宏定义来区分不同平台。

平台宏定义(T_LINUX, T_WINDOWS)，是在上一篇文章中介绍的，通过操作系统、编译器来判断当前的平台是什么，然后定义出统一的平台宏定义为我们自己所用：样的方式，把所有平台代码全部放在 API 函数中了，通过平台宏定义进行条件编译，因为代码比较短小，看起来还不错。

方案2

把不同平台的实现代码放在独立的文件中，然后通过 #include 预处理符号，在 API 函数中，把平台相关的代码引入进来。

也就是再增加 2 个文件：

（编辑：南通站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!