Fork me on GitHub

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

前言

先看一段代码

#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

#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的情况的。

 

 

posted @ 2018-12-25 13:22  克拉默与矩阵  阅读(568)  评论(0编辑  收藏  举报