2010-08-11 79 views
8

我現在做以下和編譯器(MSVC2008 /和2010)並沒有抱怨,但我不知道這是否是一個壞主意與否:#endif合法後是否有令牌?

#ifndef FOO_H_ 
#define FOO_H_ 

// note, FOO_H_ is not a comment: 
#endif FOO_H_ 

以前我總是寫它作爲#endif // FOO_H_,但我今天發現自己沒有這樣做,並認爲這很奇怪,因爲顯然我還沒有完成評論方法一段時間。

這是不好的做法,我應該回去通過我的所有標題和修復(這是一個跨平臺的應用程序),還是可以保持它的方式嗎?

+0

我收到GCC(額外令牌)的警告,所以我不會建議這樣做。 – UncleBens 2010-08-11 18:46:52

+0

我試圖問一下標準是否可以接受 - 或者如果它是特定的實現或其他 - 我不太確定。也許最好的措辭應該是「這是正確的嗎?」 - 無論哪種方式,當應用程序在其他操作系統上編譯時,我不希望發出警告,因此我將刪除它們 - 謝謝。 – 2010-08-11 18:52:17

+0

@Joe:對不起,我看錯了這個問題。 – GManNickG 2010-08-11 18:53:00

回答

6

嚴格地說(根據標準中的語法),在同一行上的#endif指令後面不允許使用標記(註釋是可以的,因爲它們在翻譯的早期階段被移除,而不是預處理指令 - 階段3與4)。

但是,MSVC似乎允許它 - 我不會去尋求解決這些問題(因爲它們不會導致問題),但可能會在修改頭文件時修復它們擁有他們。

當然,如果您的其他支持的編譯器發佈有關它們的診斷信息,修復它們可能更加緊迫。

+0

我的主要擔心是,當應用程序被移植到其他操作系統的時候,如果這種行爲不被允許,可能會導致一些事情,因爲它不是我只會修復它。無論如何不應該花太長的時間。雖然謝謝! – 2010-08-11 18:54:34

5

這是不好的,它是無效的,AFAIK。許多編譯器忽略了#endif之後的額外文本,並經常提醒他們。您應該添加//以使其成爲評論。

+0

好的,我不想看到任何警告,所以我會回去修復它,謝謝! – 2010-08-11 18:53:07

4

與其他人發佈的內容一樣,我想我可能會幫助您實際糾正問題。 (假設它在很多文件中)。

您可以使用visual studio中的查找和替換功能一次性更正所有有問題的行。只需設置查找內容:至"\#endif {[a-zA-Z\.\_]+}$"並替換爲:至"#endif //\1"(並確保您有使用:[正則表達式]在查找選項下進行檢查。)

並且在整個解決方案上做到這一點,您應該很好。

(請備份您的第一個項目,我已經測試了這一點,它似乎打算,但需要您自擔風險使用此奏效。)

+0

哦,現在這真棒,我不知道你可以在查找和替換框中使用正則表達式。雖然我對他們不是很好,但它告訴我「模式中出現語法錯誤」並突出顯示「#endif {[a-zA-Z ._] +} $」 - 我在做什麼不正確? - 編輯:哎呀,不能使用那裏的#或者打破它。它現在正在工作,非常感謝你! – 2010-08-11 19:04:35

+0

在#前面應該有斜槓(\),。和_。不知道爲什麼他們被刪除? (像這樣:\ #endif {[a-zA-Z \。\ _] +} $) – TJMonk15 2010-08-11 19:06:37

+0

@ Joe.F它在_之前刪除了那個。不知道爲什麼。只需添加它,你就會很好。 – TJMonk15 2010-08-11 19:07:14

1

爲什麼你的編譯器應該提醒你一下吧。

說你的頭文件是這樣的:

#ifndef X 
#define X 
// STUFF 
// The next line does not contain an EOL marker (can happen) 
#endif 

現在你有這個從源頭

#include "plop.h" 
class X 
{ 
} 

當編譯器包括文件技術上展開源應該是這樣的

#define X 
// STUFF 
// The next line does not contain an EOL marker (can happen) 
#endif class X 
{ 
} 

大多數現代編譯器考慮到他可能發生的情況並粘貼額外的EOL令牌包含的文件,以防止這種情況發生(技術上不允許,但我不能想到會導致問題的情況)。

問題是,一些較老的編譯器不提供這個額外的令牌(更符合標準),但結果你可能最終編譯上面的代碼(結果他們傾向於警告你兩件事1)源文件中缺少EOL和2)#endif之後的東西