1.起源上一篇分享了跨平台的头文件是什么样子的。这个头文件对于windows平台比较有意义，因为要处理库函数的导入导出声明（dllexport，dllimport）。其实可以在这个头文件的基础上继续扩展，实现更细粒度的控制。比如：判断编译器，判断编译器的版本等等。同样，我们在源码中也会遇到一些跨平台的问题。不同的功能在不同的平台上以不同的方式实现。如何组织与这些平台相关的代码？本文将讨论这个问题。PS：文末提供了一个简单的跨平台构建代码示例。2.问题介绍假设我们写了一个库，需要实现一个功能：获取系统时间戳。作为实现库的作者，您决定提供以下API函数：t_time.h：声明接口函数（t_get_timestamp）；t_time.c：实现接口函数；下面的任务是通过不同的C库或系统实现函数调用来计算系统当前的时间戳。在Linux平台下，可以通过如下代码实现：structtimevaltv;gettimeofday(&tv,null);returntv.tv_sec*1000+tv.tv_usec/1000;在Windows平台上，可以通过如下代码实现：structtimebtp;ftime(&tp);returntp.time*1000+tp.millitm;那么问题来了：这两段平台相关的代码如何组织在一起呢？这里有3种不同的组织方式，没有优劣之分，每个人都有不同的习惯，选择适合自己和团队的方式即可。另外，这个例子中只有1个函数，而且比较短。如果这样的跨平台功能很多，而且很长，可能你的选择不一样。3.三种方案方案一直接在接口函数中，通过平台宏定义来区分不同的平台。平台宏定义（T_LINUX、T_WINDOWS）在上一篇文章中介绍过。它通过操作系统和编译器判断当前平台是什么，然后定义一个统一的平台宏定义供我们自己使用：代码组织如下：int64t_get_timestamp(){int64ts=-1;#ifdefined(T_LINUX)structtimevaltv;gettimeofday(&tv,null);ts=tv.tv_sec*1000+tv.tv_usec/1000;#elifdefined(T_WINDOWS)structtimebtp;ftime(&tp);ts=tp.time;ts=ts*1000+tp.millitm;#endifreturnts;}这样所有平台代码都放在API函数中，通过平台宏定义进行条件编译，因为代码比较短，看它看起来不错。方案二将不同平台的实现代码放在单独的文件中，然后通过#include预处理符号在API函数中引入平台相关代码。即多加两个文件：t_time_linux.c：存放linux平台下的代码实现；t_time_windows.c：存放windows平台下的代码实现；(1)t_time_linux.c#include"t_time.h"#include
