是否有可能讓源代碼「超時」（在某個時刻後變爲無效）？

我們目前正忙於從Visual Studio 2005遷移到Visual Studio 2010（使用非託管C/C++）。這意味着我們大約一半的開發人員已經在使用Visual Studio 2010，而另一半仍在使用Visual Studio 2005.最近，我遇到了一種情況，可以在Visual Studio 2010中以一種乾淨的方式編寫某種構造，但需要在Visual Studio 2005清潔少的源代碼因爲不是所有的開發商已經Visual Studio 2010中的機器上，我必須寫這樣的代碼：是否有可能讓源代碼「超時」（在某個時刻後變爲無效）？

#if _MSC_VER >= 1600 
    // clean version of the source code 
#else 
    // less clean version 
    // of the source code 
    // requiring multiple lines of code 
    // and requiring some dirty static_casts 
#endif

由於所有的開發商將被遷移到Visual Studio 2010中今年年底，我希望這段代碼在一段時間後自動'消失'。在源代碼中保留「不太乾淨的版本」會導致長期不可讀的源代碼。

當然，我知道代碼不會自動消失，所以實際上我需要一段時間後自動報警。事情是這樣的：

#if _MSC_VER >= 1600 
    // clean version of the source code 
#else 
    // less clean version 
    // of the source code 
    // requiring multiple lines of code 
    // and requiring some dirty static_casts 
#endif 
#if compilation_date is after 1 november 2010 
# error "Remove Visual Studio 2005 compatibility code from this file" 
#endif

這樣一來，如果我們忘記了這一點，我們會自動後11月1日通報的2010年這個

此招可能需要使用DATE的，但由於這需要要由預編譯器處理，您不能執行字符串操作或使用C日期/時間函數。

我也考慮過發送自己延遲郵件的另一種想法，但我想知道是否沒有可以在源代碼中內置的解決方案。

來源

2010-09-01 Patrick

這聽起來像清理可以很容易地腳本化，所以我不會打擾插入額外的警告，提醒開發人員刪除冗餘代碼。 – 2010-09-01 07:15:01

就我個人而言，我會選擇不相信每個人都會在預計的日期之間遷移。即使我確信會發生這種情況，但我不想爲任何人創造額外的工作，或者在我錯了的情況下阻止他們工作。

如果沒有其他問題，構建應該是可重現的。如果在十二月你意識到你需要從十月份複製一個版本呢？你不能（至少，不是沒有在生成機器上停止時鐘），因爲它不會再編譯。

所以，我應該這樣做：

support2005.h 
------------- 

// empty file 

source file 
----------- 

#include "support2005.h" 
#if _MSC_VER >= 1600 
    // clean version of the source code 
#else 
    // less clean version 
    // of the source code 
    // requiring multiple lines of code 
    // and requiring some dirty static_casts 
#endif

一旦每個人都有VS 2010，變化support2005.h包含#error "Remove Visual Studio 2005 compatibility code from this file"。

其實我個人不會檢查這個變化，因爲它會阻止任何人在VS 2005支持被移除之前做任何工作。去除死代碼真的是貴公司11月1日上午可能擁有的最高優先級任務嗎？而且這是否需要甲板上的所有人才能這樣做？相反，我會檢查，刪除文件，完成構建，繼續刪除兼容性代碼，直到所有內容再次生成，並檢查整個內容，「刪除VS 2005支持」。

你說你擔心你可能會忘記，但如果你這樣做，那又如何？死代碼不會傷害任何人。下次您查看任何這些文件時，或下次在文件列表，標題依賴關係圖等中看到「support2005.h」時，您都會記得它。因此，它不是「長期使源代碼無法讀取「，因爲長期任何看到它的人都可以忽略或刪除它。如果您有任何問題跟蹤軟件，您可以在2010-11-01之後找到第一個里程碑，並將任務附加到「刪除VS 2005支持並擺脫support2005.h」，並附上一張紙條這是目前被VS 2005仍然使用的開發人員攔截的。

如果你真的希望2010-11-01成爲一個艱難的最後期限，之後代碼會被破壞，那麼在萬聖節前一直保持到午夜，然後檢查然後改變。它並沒有按照你的要求實際上破壞代碼，但是它確實打破了從源代碼控制中刷新的任何人，因此可能破壞了構建。最重要的是，如果事實證明阻止某人完成工作，這很容易扭轉，或者可以在本地壓制。

來源

2010-09-01 11:25:35

不錯的參數。你肯定有一個關於「構建應該是可重現的」的觀點。我不同意「死代碼不傷害任何人」的做法。死代碼可能會混淆開發人員。最近，我們遇到了一個有人試圖通過修改內部數據結構來處理死代碼的問題。所以我認爲必須刪除死代碼（儘管11月1日可能不是一個好時機）。「support2005.h」的想法引發了一個更好的想法：爲什麼不使用/ D_SUPPORT2005來定義_SUPPORT2005符號，如果這個符號不在這裏，編譯失敗，但舊代碼仍然存在。 – Patrick 2010-09-01 15:43:56

夠公平的，我假設你的組織會廣泛知道這個臨時的2005年支持是必要的。如果是這樣，那麼一旦不再需要，它*不應該*混淆任何人或導致不必要的工作，因爲任何想修改它的人都可以刪除它。我同意，由於你說的原因，應該刪除一般的死代碼。 – 2010-09-01 15:57:38

如果有人刪除舊的代碼但不刪除標題，該怎麼辦？下一次他們看到錯誤時，他們不知道需要做什麼，因爲所有的舊代碼已經消失了！ – Lazer 2010-09-01 19:13:21

我只是使用像#ifdef WARN_OLD_COMPAT這樣的預處理器定義。隨着延遲的郵件，你會記住你要定義這個。

檢查編譯日期是否晚於<X>在其他方面是不可能的。

來源

2010-09-01 07:11:12

爲什麼不直接在開發時在運行時進行檢查？當然，你測試你的代碼，所以第一次有人在日期後測試它，你會得到通知。

來源

2010-09-01 07:14:10

我更喜歡在編譯時而不是在運行時檢查。 – Patrick 2010-09-01 07:29:29

就像我一樣，但在這種情況下，在運行時檢查並沒有什麼壞處。 – 2010-09-01 07:37:49

在GNU make的情況下，我不喜歡這樣寫道：

CFLAGS + = -DCURDATE = $（殼日期+％Y％M％d）

它將添加宏CURDATE到編譯器標誌，包含YYYYMMDD格式的當前時間。

所以在源，你可以做這樣的事情：

#if CURDATE > 20101101 
#error "Do whatever you have to do" 
#endif

你可以做VS這樣的事情？

來源

2010-09-01 07:47:29 qrdl

好主意，謝謝。 – Patrick 2010-09-01 08:50:38

+1，非常聰明。 – 2010-09-01 09:04:40

是否有可能讓源代碼「超時」（在某個時刻後變爲無效）？

回答

相關問題