C 語言規範 1 13 版本控制

版本控制是乙個過程，它以相容的方式對元件進行不斷的改進。如果依賴於早期版本的**重新編譯後可以適用於新版本，則元件的新版本與早期版本源**相容。相反，如果依賴於早期版本的應用程式不用重新編譯即可適用於新版本，則元件的新版本為二進位制相容。

大多數語言根本不支援二進位制相容性，而且許多語言對促進源**相容性所做甚少。實際上，某些語言所含的缺陷使得用它開發出來的元件在不斷的改進過程中，一般至少會使依賴於該元件的某些客戶端**失效。

例如，請看乙個發布名為 base 的類的基類作者的情況。在第乙個版本中，base 不包含任何 f 方法。名為 derived 的元件從 base 派生，並引入 f。此 derived 類與它所依賴的 base 類一起發布給客戶，客戶又部署到眾多客戶端和伺服器。

// author a

namespace a

}// author b

namespace b}}

從這時起，開始產生版本問題。base 的作者生成了乙個擁有自己的 f 方法的新版本。

// author a

namespace a}}

這個新版本的 base 在源**和二進位制方面都應該與初始版本相容。（如果僅新增乙個新的方法就會產相容性問題，則基類可能就永遠不能改進了。）不幸的是，base 中的新 f 使 derived 的 f 的含義不清。derived 是指重寫 base 的 f 嗎？這看上去不太可能，因為編譯 derived 時，base 還沒有 f！此外，如果 derived 的 f 的確是重寫了 base 的 f，則它必須遵守由 base 指定的協定（此協定在編寫 derived 時尚未指定）！在某些情況下，這是不可能的。例如，base 的 f 可能要求它的重寫始終呼叫基方法。derived 的 f 不可能遵守這樣的協定。

c# 通過要求開發人員明確宣告它們的意圖來解決此版本問題。在原始的**示例中，**很清楚，因為 base 甚至沒有 f。很明顯，由於不存在名為 f 的基方法，因此 derived 的 f 是乙個新方法而不是對基方法的乙個重寫。

如果 base 新增 f 並發布新版本，則在 derived 的二進位制版本中對「derived 的 f」是什麼仍很清楚：它語義上與重寫無關，不應將它視為重寫。

然而，當重新編譯 derived 時，其含義仍是不清楚的：derived 的作者可能打算讓它的 f 重寫 base 的 f 或者隱藏它。由於意圖不清，編譯器生成乙個警告，並在預設情況下使 derived 的 f 隱藏 base 的 f。此編譯過程造成了語義上的二義性（與重新編譯 derived 前相比較）。生成的警告提醒 derived 的作者 base 中存在 f 方法。

如果 derived 的 f 在語義上與 base 的 f 無關，則 derived 的作者可以通過在 f 的宣告中使用 new 關鍵字來表示此意圖（並且有效地關閉警告）。

// author a

namespace a}}

// author b

namespace b}}

另一方面，derived 的作者經過進一步考慮，可能決定 derived 的 f 應重寫 base 的 f。可以通過使用 override 關鍵字來指定此意圖，如下所示。

// author a

namespace a}}

// author b

namespace b}}

derived 的作者還有另一種選擇，就是更改 f 的名稱，從而徹底避免名稱衝突。儘管此更改會破壞 derived 的源**和二進位制相容性，但這種相容性的重要性因方案而異。如果不向其他程式公開 derived，則更改 f 的名稱很可能是個好主意，因為這會提高程式的可讀性，就是說 f 的含義不會再有任何混淆。

C 語言規範 1 13 版本控制

1 版本控制

UE4版本控制

1 版本控制系統

C 語言規範 1 13 版本控制

1 版本控制

UE4版本控制

1 版本控制系統

相關推薦