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

一、缘起

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

创新互联建站是一家专注于成都做网站、成都网站设计与策划设计,同仁网站建设哪家好?创新互联建站做网站,专注于网站建设十年,网设计领域的专业建站公司;建站业务涵盖:同仁等地区。同仁做网站价格咨询:13518219792

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

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

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

二、问题引入

假设我们写一个库,需要实现一个函数:获取系统时间戳。作为实现库的作者,你决定提供下面的 API 函数:

 
 
 
 
  1. t_time.h: 声明接口函数(t_get_timestamp); 
  2. t_time.c:实现接口函数; 

下面的任务就是在函数实现中,通过不同下的 C 库或系统调用,来计算系统当前的时间戳。

在 Linux 平台下,可以通过下面这段代码实现:

 
 
 
 
  1. struct timeval tv; 
  2. gettimeofday(&tv, null); 
  3. return tv.tv_sec * 1000 + tv.tv_usec / 1000; 

在 Windows 平台下,可以通过下面这段代码实现:

 
 
 
 
  1. struct timeb tp; 
  2. ftime(&tp); 
  3. return tp.time *1000 + tp.millitm; 

那么问题来了:怎么把这两段平台相关的代码组织在一起?下面就介绍 3 种不同的组织方式,没有优劣之分,每个人都有不同的习惯,选择适合自己和团队的方式就行。

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

三、三个解决方案

方案1

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

平台宏定义(T_LINUX, T_WINDOWS),是在上一篇文章中介绍的,通过操作系统、编译器来判断当前的平台是什么,然后定义出统一的平台宏定义为我们自己所用:

代码组织方式如下:

 
 
 
 
  1. int64 t_get_timestamp() 
  2.     int64 ts = -1; 
  3.      
  4. #if defined(T_LINUX) 
  5.     struct timeval tv; 
  6.     gettimeofday(&tv, null); 
  7.     ts = tv.tv_sec * 1000 + tv.tv_usec / 1000; 
  8. #elif defined(T_WINDOWS) 
  9.     struct timeb tp; 
  10.     ftime(&tp); 
  11.     ts = tp.time; 
  12.     ts = ts *1000 + tp.millitm; 
  13. #endif 
  14.  
  15.     return ts; 

这样的方式,把所有平台代码全部放在 API 函数中了,通过平台宏定义进行条件编译,因为代码比较短小,看起来还不错。

方案2

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

也就是再增加 2 个文件:

 
 
 
 
  1. t_time_linux.c:存放 Linux 平台下的代码实现; 
  2. t_time_windows.c:存放 Windows 平台下的代码实现; 

(1) t_time_linux.c

 
 
 
 
  1. #include "t_time.h" 
  2. #include  
  3.  
  4. int64 t_get_timestamp() 
  5.     int64 ts = -1; 
  6.      
  7.     struct timeval tv; 
  8.     gettimeofday(&tv, null); 
  9.     ts = tv.tv_sec * 1000 + tv.tv_usec / 1000; 
  10.      
  11.     return ts; 

(2) t_time_windows.c

 
 
 
 
  1. #include "t_time.h" 
  2. #include  
  3. #include  
  4.  
  5. int64 t_get_timestamp() 
  6.     int64 ts = -1; 
  7.      
  8.     struct timeb tp; 
  9.     ftime(&tp); 
  10.     ts = tp.time; 
  11.     ts = ts *1000 + tp.millitm; 
  12.  
  13.     return ts; 

(3) t_time.c

这个文件不做任何事情,仅仅是 include 其他的代码。

 
 
 
 
  1. #include "t_time.h" 
  2.  
  3. #if defined(T_LINUX) 
  4. #include  
  5. #elif defined(T_WINDOWS) 
  6. #include  
  7. #else 
  8. int64 t_get_timestamp() 
  9.     return -1; 
  10. #endif 

有些人比较反感这样的组织方式,一般都是 include 一个 .h 头文件,而这里通过平台宏定义,include 不同的 .c 源文件,感觉怪怪的?!

其实,也有一些开源库是这么干的,比如下面:

方案3

在上面方案2中,是在源代码中填入不同平台的实现代码。

其实可以换一种思路,既然已经根据平台的不同、放在不同的文件中了,那么可以让不同的源文件加入到编译过程中就可以了。

测试代码是使用 cmake 工具来构建的,因此可以编辑 CMakelists.txt 文件,来控制参与编译的源文件。

CMakelists.txt 文件部分内容

 
 
 
 
  1. # 设置平台变量 
  2. if (CMAKE_SYSTEM_NAME MATCHES "Linux") 
  3. set(PLATFORM linux) 
  4. elseif (CMAKE_SYSTEM_NAME MATCHES "Windows") 
  5. set(PLATFORM windows) 
  6. endif() 
  7.  
  8. # 根据平台变量,来编译不同的源文件 
  9. set(LIBSRC  t_time_${PLATFORM}.c) 

这样的组织方式,感觉代码更“干净”一些。同样的,我们也可以看到一些开源库也是这么做的:

四、One More Thing

为了文章的篇幅,以上只是贴了代码的片段。

我写了一个最简单的 demo,使用 cmake 来构建跨平台的动态库、静态库、可执行程序。写这个 demo 的目的,主要是作为一个外壳,来测试一些写文章时的代码。

在 Linux 平台下,通过 cmake 指令手动编译;在 Windows 平台下,可以通过 CLion 集成开发环境直接编译、执行,也可以通过 cmake 工具直接生成 VS2017/2019 解决方案。

已经把这个 demo 放在 gitee 仓库中了,感兴趣的小伙伴,请在公众号回复:dg36,即可收到克隆地址。

文章标题:详解跨平台代码的3种组织方式
文章分享:http://www.shufengxianlan.com/qtweb/news46/26496.html

网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联