关于header file、static、inline、variable hides的一点感想

前言

先看一段代码

?

1 2 3 4 5 6 7 8 9 10 11 12 13

#ifndef  _INLINE_H #define  _INLINE_H   template<typename T> static inline T my_max(T a, T b) {     a *= 2;     b /= 3;     return (a>b) ? a : b;  //找出最大值 }   #endif

代码本身逻辑很简单，无外乎简单的找出两个T类型变量中大者。

这里有几个关键字的用法很值得深究，特此记录下感想。

inline

简单的理解inline就是，他只有带参宏的优点，没有带参宏的缺点。但实际情况，这可能仅仅是Programmer的一厢情愿。因为啥？ inline和register的行为很像，正确的理解方式是，这两个关键字是programmer对compiler的一种建议。至于你的建议会不会被compiler所接纳，那是compiler的事，我们不应该对compiler有任何假设。因此上面代码中是对然你加了inline，最终效果可能和不加inline的normal function一样。

static

要想理解此处static的作用，首先想像我们经常遇到的重复定义error。软件开发中遇到的重复定义error，99%都是来自于global空间被“污染”。为啥这么说？对于文件作用域内的variable or function，重复定义情况你是很容易发现的，都写在一个文件中，打眼一看就知道有没有冲突。然而实际开发中，多人协作开发，global空间有啥东西谁也不清楚。对于那些拍脑子乱加global variable or function 的人更是如此，可能他自己“污染”了global空间，自己都不知道。

想想哪些地方可能会导致global空间被“污染”，嗯....头文件（.h）和.c文件

.h文件

对于在.h里面的强符号，应该始终秉持这样一种观点：尽可能将header files封锁在include他的单个.c文件。除非对那些必须要共享的variable or function，其余强符号最好加上static。虽然header guard帮我们避免了一份头文件多次包含的情况，确保整个头文件在最终可执行文件中只有一份。但是header guard无法保证header files中的强符号与其他人.h  or  .c文件中的强符号发生重复定义风险。

.c文件 

对于.c中的强符号，如果不想被他人使用 或者 可能给他人带来风险，最好加上static，将其锁死在文件作用域。

软件开发是个多人合作活动，对于编码问题上的风险，我们应该将其扼杀在萌芽中。一个良好的编码规范无疑是重要的。核心代码必须有企业自己把握，业务代码（简单扩充函数）完全可以外包出去，外包出去的代码质量由公司内部人员把控。这样可以进一步缩减人力成本。

variable hides

?

1 2 3 4 5 6 7 8 9

#include <stdio.h>   int var = 20; int main() {    int var = var;    printf("%d\n", var);    return 0; }

variable hides很好理解，The local variable always hides a global one of the same name as soon as it's declared.

那么换成function hides呢？

我们知道C不支持overloading，C++支持overloading。C++下最终识别到的函数名字类似于这样：

那有没有这种可能？

某个.c内的static function 和 某个 global function在compiler那一侧解析的名字完全一致，那不就会存在类似于variable hides的情况了吗？虽然这种情况概率比较低，但是面对百万行代码的时候还是难免不会遇到。

事实上，这个问题完全是多虑了。

之所以会想到这个奇怪的问题，其根源是对作用域问题的思考。上层上讲就是谁的作用域有效，低层上函数名就是个地址，地址值都不一样。因此最终翻译成二进制代码的时候是不会出现function hides的情况的。