關於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的狀況的。