在＃ifndef's中包含＃包含 - 是否添加任何值？

Question

我繼承了C/C++代碼庫，並且在許多.cpp文件中，#include指令被封裝在#ifndef的頭部內部單個包括#define中。

例如

#ifndef _INC_WINDOWS 
#include <windows.h> 
#endif 

和WINDOWS.H看起來像

#ifndef _INC_WINDOWS 
#define _INC_WINDOWS 
...header file stuff.... 
#endif // _INC_WINDOWS 

我認爲這樣做是爲了加快代碼的編譯/預處理。

我認爲這是醜陋的和過早的優化，但由於項目有5分鐘的清理時間，我不想讓事情變得更糟。

那麼這種做法是否會增加任何價值或加快速度？清理它們可以嗎？

更新：編譯器是MSVC（VS2005）和平臺的Win32/WinCE的

Answer 1

值得知道一些實現有#pragma once和/或一個頭，包括 - 保護檢測優化，並且在這兩種情況下，預處理器都會自動跳過打開，讀取或處理之前包含的頭文件。

所以在這些編譯器上，包括MSVC和GCC，這個「優化」是沒有意義的，它應該是頭文件處理多重包含的責任。但是，這可能是對#include效率非常低的編譯器的優化。代碼在病態上是否可移植，並且<windows.h>不是指着名的Win32頭文件，而是指某個用戶定義的同名頭文件？

頭文件也可能沒有多重保護，而且這種檢查實際上是必不可少的。在這種情況下，我會建議更改標題。標題的全部內容代替了關於該地點的複製和粘貼代碼：它不應該包含三行來包含標題。

編輯：

既然你說你只關心MSVC，我要麼：

• 做大規模修改，時間構建公正，以確保前面的程序員不知道我的東西別。如果有幫助，可以加#pragma once。如果所有這些都會減慢速度，請使用預編譯頭文件。
• 忽略它，但不要使用新的文件的警衛或添加到舊文件的新的#include。

根據我是否有更重要的事情需要擔心。這是一個典型的星期五下午的工作，我不會花費潛在的生產時間;-)

Answer 2

如果包括文件，那麼整個文件已經被讀取，開放的，甚至架空/關閉該文件可能是顯著。通過將防範指令放在include聲明中，它永遠不必打開。與往常一樣帶着這些問題，正確的答案是：儘量取出圍繞include指令的ifndef/endif衛士，讓您的秒錶......