C++项目中常使用宏来做跨平台、功能实现隔离、变量定义的功能，这篇文章来讨论下是否所有情况下都适合用宏
小D的故事
程序员小D接到一个任务，需要给同事A提供一个复杂公式的实现。输入为一组参数，输出一个计算结果。
大致如下：
double computeSomeThing(double paramA,double paramB,double paramC);
小D很快完成了。过了几天同事A又来找他，说现在需要提升该函数的性能，建议改为在float类型上，用一些SIMD指令。且同事A表示不是很愿意修改接口。于是小D在考虑以下两点后决定用一个宏把原来double的实现和float的实现分开来。
1、上层需求变动性比较大，说不定哪天又要用double了。所以还是保留double类型的实现
2、用宏把两份代码隔开来，互相不影响比较省事
于是代码就变成了这样：
|
1
2
3
4
5
6
7
8
9
10
|
double computeSomeThing(double paramA,double paramB,double paramC)
{
#ifdef _USE_DOUBLE_
// do something in double
#else
// convert dobule to float
// do something in float
// convert float to double
#endif
}
|
同事A很满意，因为他只要替换一下.so或.a即可，代码层不需要改动。于是和小D合作开发了很多这样的函数，并且都有float和double两种实现。在对性能要求高的时候要求小D提供float版本；性能要求低，精度要求的时候要求小D提供double版本。
此时小D会在出库的时候感到一丝不方便。第一，版本号中需要区分float和double版本。
第二，因为用宏隔开，切换两个版本的时候需要重新编译，而代码量很多所以编译时间很长，但这些都是能克服的。
直到有一天同事小B的模块也需要这个库，并且小A和小B的模块要组合起来给小C用，最要命的是小A和小B的模块分别要用float版本和double版本。所以此时应该提供float版本so还是提供double版本so呢。
问题分析
在上面的场景中，小D作为一个基础库的提供者不应该因为同事不愿意修改接口或者图方便用宏去隔离功能，使得一个接口有了二义性。比较合适的一种做法是，再提供一个控制选择变量，来选择用哪种实现，即允许运行时决定用float还是double版本。
double computeSomeThing(double paramA,double paramB,double paramC,bool isFast);
或者小A就是不愿意改接口（考虑实际项目中，接口参数复杂且调用分散在各处），那么也可以通过增加接口实现。
double computeSomeThing(double paramA,double paramB,double paramC);
void setFast(bool isFast);
下面的情况用宏做隔离就是比较合理的选择。
比如一套代码要分别运行在linux和windows上，依赖的头文件、部分基础函数接口都是有区别的。此时用宏去隔离就比较合理。因为这两个版本在运行时永远不会同时出现。除了平台差异性外，版本管理也可以用宏来做隔离。
比如opencl 1.2和opencl 2.0版本相比较的话，2.0版本中新增了SVM相关的接口。当一个opencl程序未来可能运行在1.2版本的设备和2.0版本的设备上时。
可以用宏来选择是否屏蔽掉SVM接口。因为2.0的接口运行在1.2的设备上时，无法从环境中获取2.0新增的接口实现导致程序跑不起来（1.2的相关so中没有SVM函数实现）。
不过这个问题用宏来处理也不是最优的，使用dlopen可以有更灵活的实现。
总结
对于做基础库提供给很多人使用的同学，当用宏隔开的代码有可能会同时运行在一个环境时建议改为运行时选择走哪条分支。但肯定互相不兼容的时候就放心的用宏吧，比如跨操作系统。
另外提一下，对于有很多代码的大项目用宏的时候也要慎重考虑一下，不要动不动就用宏去做一些功能开关，因为编译时间太长是很影响效率的。
比如有以下宏定义：
|
1
2
3
4
5
6
|
#define _OPEN_LOG_
#ifdef _OPEN_LOG_
#define LOG_PRINT(...) printf(...)
#else
#define LOG_PRINT(...)
#endif
|
开发阶段代码中到处插着LOG_PRINT的使用，发布时关闭打印又是一波整个项目重新编译。再多来几个这种功能，每次切换又是整个项目重新编译，非常烦人。可以用函数指针代替:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
typedef void (*LogPrint)(const char * pstrMsg);
LogPrint g_LogPrint;
void LogPrint_Imp(const char *pstrMsg)
{
printf("%s\n",pstrMsg);
return;
}
void LogPrint_Empty(const char *pstrMsg)
{
return;
}
int main(int argc,char **argv)
{
// 此处对日志功能进行开关
g_LogPrint = LogPrint_Imp ;
//g_LogPrint = LogPrint_Empty ;
// .....
}
void someFun()
{
g_LogPrint("in someFun"); //到底打印还是不打印，运行时决定
}
|
在这个例子中，关闭日志时编译器只会对main函数所在的文件进行重新编译，就不用费时费力的重新编译整个项目了。而且还可以把g_LogPrint的赋值的行为通过接口开放到上层，由调用者决定是否需要打开log。
再举个例子，有些人喜欢项目中各个代码模块中用到的参数提到一个头文件中，然后各个.c都包含这个头文件。就像这样：
|
1
2
3
4
5
6
7
8
|
// GobalParam.h
#ifndef XX_XX
#define XX_XX
#define DETECTION_MAX 100
#define INPUT_WIDTH_MAX 4096
#define INPUT_HEIGHT_MAX 4096
// 诸如此类很多宏
#endif
|
我个人觉得下面这种实现更好
|
1
2
3
4
5
6
7
8
|
// GobalParam.h
#ifndef XX_XX
#define XX_XX
extern const int DETECTION_MAX;
extern const int INPUT_WIDTH_MAX ;
extern const int INPUT_HEIGHT_MAX ;
// 在某个.c或.cpp中赋值 :const int INPUT_HEIGHT_MAX = 100；
#endif
|
这样你对某个参数修改的时候，就不用眼巴巴的等着所有包含此头文件的编译模块重新编译了。
以上为个人经验，希望能给大家一个参考，也希望大家多多支持服务器之家。如有错误或未考虑完全的地方欢迎留言讨论，望不吝赐教。
原文链接：https://blog.csdn.net/XiaoHeiBlack/article/details/102522788