將程序從托管擴展 C++ 遷移到 C++/CLI(1)

2019-11-17 05:16:04

字體：大中小

來源：轉載

供稿：網友

簡介 C++/CLI代表 ISO-C++標準語言的一個動態編程泛型擴展 (dynamic PRogramming paradigm extension)。在原版語言設計 (V1) 中有許多顯著的弱點，我們覺得在修訂版語言設計 (V2) 中已經修正了這些弱點。本文列舉了 V1 版本語言的功能和它們在 V2 版本中的對應功能（假如存在）；并指出了其對應功能不存在的構造。對于有愛好的讀者，可以查看附錄中提供新語言設計的擴展原理。另外，一個源代碼級別的轉換工具 (mscfront) 正在開發中，而且可能在 C++/CLI的發布版中提供給希望將 V1 代碼自動移植到新語言設計的人。本文分為五個章節加一個附錄。第一節討論語言要害字的主要問題，非凡是雙下劃線的移除以及與上下文相關和由空格分隔的要害字。第二節著眼于托管類型的變化 — 非凡是托管引用類型和數組。還可以在這里找到有關確定性終結語義（deterministic finalization）的具體討論。關于類成員的變化，例如屬性、索引屬性和操作符，是第三節的重點。第四節著眼于 CLI 枚舉、內部和釘住指針的語法變化。它也討論了許多可觀的語義變化，例如隱式裝箱的引入、CLI枚舉的變化，和對值類中默認構造函數的支持的移除。第五節有點像大雜燴 — 亂七八糟的雜項。討論了類型轉換符號、字符串字符的行為和參數數組。 1. 語言要害字 原版到修訂版語言設計的一個重要轉換是在所有要害字中去掉雙下劃線。舉例來說，一個屬性現在被聲明為 property而不是 __property。在原版語言設計中使用雙下劃線前綴的兩個主要原因是： 1.這是提供符合 ISO-C++標準的本地擴展的一致性方法。原版語言設計的一個主要目標就是不引入與標準語言的不兼容性，例如新的要害字和標記。這個原因很大程度上也推動了對聲明托管引用類型的對象的指針語法的選擇。 2.雙下劃線的使用，除了兼容性方面的原因之外，也是一個不會對有舊代碼基礎的用戶造成影響的合理保證。這是原版語言設計的第二主要目標。這樣的話，為什么我們移除雙下劃線（并且引入了一些新的標記）？不是的，這并不代表我們不再考慮和標準保持一致！我們繼續致力于和標準一致。盡管如此，我們意識到對 CLI動態對象模型的支持表現出了一種全新的強大的編程范型。我們在原版語言設計上的經驗以及設計與發展 C++ 語言本身的經驗使我們確信，對這個新范型的支持需要它自己的高級要害字和標記。我們想提供一個該新范型的一流表達方式，整合它并且支持標準語言。我們希望您會感受到修訂版語言設計提供了對這兩種截然不同的對象模型的一流的編程體驗。類似的，我們很關心最小化這些新的要害字的對現有代碼可能造成的沖擊。這是用與上下文相關和由空格分隔的要害字來解決的。在我們著眼于實際語言語法的修訂之前，讓我們試試搞清楚這兩個非凡要害字的特點。一個與上下文相關的要害字在特定的程序上下文中有非凡的含義。例如，在通常的程序中，sealed 是一個普通標識符。但是，在一個托管引用類類型的聲明部分，它就是類聲明上下文中的一個要害字。這使得在語言中引入一個新的要害字的潛在影響降到最低程度，我們認為，這對已經擁有代碼基的用戶非常重要。同時，它答應新功能的使用者獲得一流的新增語言功能的體驗 — 我們認為在原版語言設計中缺少這些因素。我們將在 2.1.2節中看到 sealed用法的示例。一個由空格分隔的要害字是與上下文相關要害字的特例。它在字面上將一個與上下文相關的修飾符和一個現存的要害字配對，用空格分隔。這個配對作為一個單獨的單位，例如 value class(示例參見 1.1 節)，而不是兩個單獨的要害字。基于現實的因素，這意味著一個重新定義 value 的宏，如下所示： #ifndef __cplusplus_cli #define value 不會在一個類聲明中去掉 value。假如確實要這么做的話，必須重新定義單元對，編寫如下代碼： #ifndef __cplusplus_cli 考慮到現實的因素，這是十分必要的。否則，現存的 #define可能轉換由空格分隔的要害字的與上下文相關的要害字部分。 2.托管類型
聲明托管類型和創建以及使用這些類型的對象的語法已經大加修改，以提高 ISO-C++類型系統內的集成性。這些更改在后面的小節中詳述。委托的討論延后到 2.3節以用類中的事件成員表述它們 — 這是第 2 節的主題。(有關更加具體的跟蹤引用語法介紹的內幕和設計上的主要轉變的討論，請參見附錄A：推動修訂版語言設計。）

2.1 聲明一個托管類類型

在原版語言定義中，一個引用類類型以 __gc要害字開頭。在修訂版語言中，__gc要害字被兩個由空格分隔的要害字 ref class或者 ref strUCt之一替代。struct或者 class的選擇只是指明在類型體中開頭未標記部分聲明的其成員的公共(對于 struct)或者私有(對于 class)默認訪問級別。類似地，在原版語言定義中，一個 value 類類型以 __value 要害字開頭。在修訂版語言中，__value 要害字被兩個由空格分隔的要害字 value class或者 value struct之一代替。在原版語言設計中，一個接口類型是用要害字 __interface指明的。在修訂版語言中，它被 interface class替代。例如，下列類聲明對 // 原版語法 public __gc class Block { ... }; // 引用類 public __value class Vector { ... }; // 值類 public __interface IMyFile { ... }; // 接口類在修訂版語言設計下等價的聲明如下： // 修訂版語法 public ref class Block { ... }; public value class Vector { ... }; public interface class IMyFile { ... }; 選擇 ref(對于引用類型)而不是 gc(對于垃圾收集類型)是為了便于更好地暗示這個類型的本質。2.1.1指定一個類為抽象類型在原版語言定義中，要害字 __abstract放在類型要害字之前(__gc之前或者之后)以指明該類尚未完成，而且此類的對象不能在程序中創建： public __gc __abstract class Shape {}; public __gc __abstract class Shape2D: public Shape {}; 在修訂版語言設計中，abstract 與上下文相關的要害字被限定在類名之后，類體、基類派生列表或者分號之前。 public ref class Shape abstract {}; public ref class Shape2D abstract : public Shape{}; 當然，語義沒有變化。2.1.2指定一個類為密封類型在原版語言定義中，要害字 __sealed放在 class 要害字之前(__gc之前或者之后)以指明類的對象不能從以下類繼續： public __gc __sealed class String {};
在 V2語言設計中，與上下文相關的抽象要害字限定在類名之后，類體、基類派生列表或者分號之前(您可以聲明一個繼續類并密封它。舉例來說，String類隱式派生自Object)。密封一個類的好處是答應靜態(即在編譯時)解析這個密封引用類對象的所有的虛函數調用。這是因為密封指示符保證了 String跟蹤句柄不能指向一個可能重載被調用的虛方法實例的派生類。 public ref class String sealed {}; 也可以將一個類既聲明為抽象類也聲明為密封類。這是一種被稱為靜態類的非凡情況。這在CLI文檔中描述如下：同時為抽象和密封的類型只能有靜態成員，并且以一些語言中調用命名空間一樣的方式服務。例如，以下是一個使用 V1語法的抽象密封類的聲明 public __gc __sealed __abstract class State { public: static State(); static bool inParamList(); private: static bool ms_inParam; }; 而以下是在修訂版語言設計中的聲明： public ref class State abstract sealed { public: static State(); static bool inParamList(); private: static bool ms_inParam; }; 2.1.3 CLI繼續: 指定基類在 CLI對象模型中，只支持公有方式的單繼續。但是，在原始語言定義中仍然保留了ISO-C++對基類的默認解釋，而無需訪問要害字指定私有派生。這意味著每一個 CLI繼續聲明必須用一個 public要害字來代替默認的解釋。很多用戶認為編譯器似乎過于嚴謹。// V1:錯誤：默認為私有派生 __gc class My : File{}; 在修訂版語言定義中，CLI繼續定義缺少訪問要害字時，默認是以公有的方式派生。這樣，公有訪問要害字就不再必要，而是可選的。雖然這個改變不需要對 V1的代碼做任何的修改，出于完整性考慮我仍將這個變化列出。// V2:正確：默認是公有性派生 ref class My : File{};

簡介 C++/CLI代表 ISO-C++標準語言的一個動態編程泛型擴展 (dynamic programming paradigm extension)。在原版語言設計 (V1) 中有許多顯著的弱點，我們覺得在修訂版語言設計 (V2) 中已經修正了這些弱點。本文列舉了 V1 版本語言的功能和它們在 V2 版本中的對應功能（假如存在）；并指出了其對應功能不存在的構造。對于有愛好的讀者，可以查看附錄中提供新語言設計的擴展原理。另外，一個源代碼級別的轉換工具 (mscfront) 正在開發中，而且可能在 C++/CLI的發布版中提供給希望將 V1 代碼自動移植到新語言設計的人。本文分為五個章節加一個附錄。第一節討論語言要害字的主要問題，非凡是雙下劃線的移除以及與上下文相關和由空格分隔的要害字。第二節著眼于托管類型的變化 — 非凡是托管引用類型和數組。還可以在這里找到有關確定性終結語義（deterministic finalization）的具體討論。關于類成員的變化，例如屬性、索引屬性和操作符，是第三節的重點。第四節著眼于 CLI 枚舉、內部和釘住指針的語法變化。它也討論了許多可觀的語義變化，例如隱式裝箱的引入、CLI枚舉的變化，和對值類中默認構造函數的支持的移除。第五節有點像大雜燴 — 亂七八糟的雜項。討論了類型轉換符號、字符串字符的行為和參數數組。 1. 語言要害字原版到修訂版語言設計的一個重要轉換是在所有要害字中去掉雙下劃線。舉例來說，一個屬性現在被聲明為 property而不是 property。在原版語言設計中使用雙下劃線前綴的兩個主要原因是： 1.這是提供符合 ISO-C++標準的本地擴展的一致性方法。原版語言設計的一個主要目標就是不引入與標準語言的不兼容性，例如新的要害字和標記。這個原因很大程度上也推動了對聲明托管引用類型的對象的指針語法的選擇。 2.雙下劃線的使用，除了兼容性方面的原因之外，也是一個不會對有舊代碼基礎的用戶造成影響的合理保證。這是原版語言設計的第二主要目標。這樣的話，為什么我們移除雙下劃線（并且引入了一些新的標記）？不是的，這并不代表我們不再考慮和標準保持一致！我們繼續致力于和標準一致。盡管如此，我們意識到對 CLI動態對象模型的支持表現出了一種全新的強大的編程范型。我們在原版語言設計上的經驗以及設計與發展 C++ 語言本身的經驗使我們確信，對這個新范型的支持需要它自己的高級要害字和標記。我們想提供一個該新范型的一流表達方式，整合它并且支持標準語言。我們希望您會感受到修訂版語言設計提供了對這兩種截然不同的對象模型的一流的編程體驗。類似的，我們很關心最小化這些新的要害字的對現有代碼可能造成的沖擊。這是用與上下文相關和由空格分隔的要害字來解決的。在我們著眼于實際語言語法的修訂之前，讓我們試試搞清楚這兩個非凡要害字的特點。一個與上下文相關的要害字在特定的程序上下文中有非凡的含義。例如，在通常的程序中，sealed 是一個普通標識符。但是，在一個托管引用類類型的聲明部分，它就是類聲明上下文中的一個要害字。這使得在語言中引入一個新的要害字的潛在影響降到最低程度，我們認為，這對已經擁有代碼基的用戶非常重要。同時，它答應新功能的使用者獲得一流的新增語言功能的體驗 — 我們認為在原版語言設計中缺少這些因素。我們將在 2.1.2節中看到 sealed用法的示例。一個由空格分隔的要害字是與上下文相關要害字的特例。它在字面上將一個與上下文相關的修飾符和一個現存的要害字配對，用空格分隔。這個配對作為一個單獨的單位，例如 value class(示例參見 1.1 節)，而不是兩個單獨的要害字。基于現實的因素，這意味著一個重新定義 value 的宏，如下所示： #ifndef cplusplus_cli #define value 不會在一個類聲明中去掉 value。假如確實要這么做的話，必須重新定義單元對，編寫如下代碼： #ifndef __cplusplus_cli 考慮到現實的因素，這是十分必要的。否則，現存的 #define可能轉換由空格分隔的要害字的與上下文相關的要害字部分。 2.托管類型
聲明托管類型和創建以及使用這些類型的對象的語法已經大加修改，以提高 ISO-C++類型系統內的集成性。這些更改在后面的小節中詳述。委托的討論延后到 2.3節以用類中的事件成員表述它們 — 這是第 2 節的主題。(有關更加具體的跟蹤引用語法介紹的內幕和設計上的主要轉變的討論，請參見附錄A：推動修訂版語言設計。）

2.1 聲明一個托管類類型

在原版語言定義中，一個引用類類型以 __gc要害字開頭。在修訂版語言中，__gc要害字被兩個由空格分隔的要害字 ref class或者 ref struct之一替代。struct或者 class的選擇只是指明在類型體中開頭未標記部分聲明的其成員的公共(對于 struct)或者私有(對于 class)默認訪問級別。類似地，在原版語言定義中，一個 value 類類型以 __value 要害字開頭。在修訂版語言中，__value 要害字被兩個由空格分隔的要害字 value class或者 value struct之一代替。在原版語言設計中，一個接口類型是用要害字 __interface指明的。在修訂版語言中，它被 interface class替代。例如，下列類聲明對 // 原版語法 public __gc class Block { ... }; // 引用類 public __value class Vector { ... }; // 值類 public __interface IMyFile { ... }; // 接口類在修訂版語言設計下等價的聲明如下： // 修訂版語法 public ref class Block { ... }; public value class Vector { ... }; public interface class IMyFile { ... }; 選擇 ref(對于引用類型)而不是 gc(對于垃圾收集類型)是為了便于更好地暗示這個類型的本質。2.1.1指定一個類為抽象類型在原版語言定義中，要害字 __abstract放在類型要害字之前(__gc之前或者之后)以指明該類尚未完成，而且此類的對象不能在程序中創建： public __gc __abstract class Shape {}; public __gc __abstract class Shape2D: public Shape {}; 在修訂版語言設計中，abstract 與上下文相關的要害字被限定在類名之后，類體、基類派生列表或者分號之前。 public ref class Shape abstract {}; public ref class Shape2D abstract : public Shape{}; 當然，語義沒有變化。2.1.2指定一個類為密封類型在原版語言定義中，要害字 __sealed放在 class 要害字之前(__gc之前或者之后)以指明類的對象不能從以下類繼續： public __gc __sealed class String {};
在 V2語言設計中，與上下文相關的抽象要害字限定在類名之后，類體、基類派生列表或者分號之前(您可以聲明一個繼續類并密封它。舉例來說，String類隱式派生自Object)。密封一個類的好處是答應靜態(即在編譯時)解析這個密封引用類對象的所有的虛函數調用。這是因為密封指示符保證了 String跟蹤句柄不能指向一個可能重載被調用的虛方法實例的派生類。 public ref class String sealed {}; 也可以將一個類既聲明為抽象類也聲明為密封類。這是一種被稱為靜態類的非凡情況。這在CLI文檔中描述如下：同時為抽象和密封的類型只能有靜態成員，并且以一些語言中調用命名空間一樣的方式服務。例如，以下是一個使用 V1語法的抽象密封類的聲明 public __gc __sealed __abstract class State { public: static State(); static bool inParamList(); private: static bool ms_inParam; }; 而以下是在修訂版語言設計中的聲明： public ref class State abstract sealed { public: static State(); static bool inParamList(); private: static bool ms_inParam; }; 2.1.3 CLI繼續: 指定基類在 CLI對象模型中，只支持公有方式的單繼續。但是，在原始語言定義中仍然保留了ISO-C++對基類的默認解釋，而無需訪問要害字指定私有派生。這意味著每一個 CLI繼續聲明必須用一個 public要害字來代替默認的解釋。很多用戶認為編譯器似乎過于嚴謹。// V1:錯誤：默認為私有派生 __gc class My : File{}; 在修訂版語言定義中，CLI繼續定義缺少訪問要害字時，默認是以公有的方式派生。這樣，公有訪問要害字就不再必要，而是可選的。雖然這個改變不需要對 V1的代碼做任何的修改，出于完整性考慮我仍將這個變化列出。// V2:正確：默認是公有性派生 ref class My : File{};