Visual Studio 2005中C++的變化

下一代visual studio版本（以前whidbey,現在是visual studio 2005）提供更加豐富的改進的庫文件和沒有很多幕後精簡和加速的壓力，它的大量配合的工具和新的功能將使開發者的開發過程變得簡單有趣，對我而言，這些與visual studio 2005對C++的處理相比就顯得有些蒼白，這裡我主要談談在下一代visual studio中C++的變化.

　　跟下劃線拜拜

　　在visual studio.NET中引入了對C++擴展名的處理，擴展名是以兩個下劃線開始的關鍵字，比如__gc和__property.自從上個版本發布以來，我已經寫了大量的雙下劃線特征的代碼，我坦白也不喜歡這樣，我了解具體的原因是：帶兩個下劃線的關鍵字作為特殊的擴展名使它們不會跟標准編譯器相混淆，你可以全面的管理擴展名可以用其他的編譯器來編譯，它忽視__關鍵字。

　　這是一種解決方法：微軟發現了一種方法不改變編程語言的改變，但是會出現下面一些結果：

　　·開發者發現語法不自然

　　·不能被完全的采用

　　如例，適當的C++處理方法：程序代碼：
public __gc class Foo
{
// hundreds of lines of code
__property String* get_Text();
// hundreds of lines of code
__property void set_Text(String*);
// hundreds of lines of code
}; 　　有良好習慣的程序員把get和put放在每個擴展名的右面，把潛在的變量放在旁邊，但是編程語言沒要求你這樣做。它提供無環境支持定界結構讓你明白作為一個單元是正確的，所以它是不自然的跟其它visual studio .NET語言不一樣。但是你如何去處理這個問題那，唯一的方式完成C++轉換成CLR反之就要改變C++.假如你想那樣做，你可以有足夠的自由得到自然一流的語言會給你最好的，你可以取消大量的帶雙劃線的關鍵字。

　　生存時間和范圍

　　 我喜歡確定的解析，實際上我也喜歡碎片收集，我還能舉出更多的，它們有自己的作用而且我也需要它們，假如我只在內存中構造一個對象，我希望在我自己清除它前不被清除，

　　 所以內存管理是很復雜的。但是，如果你的對象包含一個非管理的源文件如數據庫鏈接，一個開放文件，或者類似我要取得一個控制。我想知道它要盡快的離開，用這種模式去處理，但是它不是直接的，簡單的親密支持是最好的辦法。

　　 下面是在原始的C++中，你去完成這些事情：程序代碼：

//this is a code fragment
{
try
{
Foo* f=new Foo(/* params */);
//all kinds of code, some of which might throw exceptions
delete f;
}

catch (/* something */)
{
delete f;
//whatever else, or rethrow;
}
}

如果你在堆棧建立對象，生命期是簡單的

程序代碼：

//this is a code fragment
{
　 Foo f;
　 //all kinds of code, some of which might throw exceptions
}

當f超過范圍，不論是否是意外它將被清除這是自然的。

　　當對象在管理堆裡時，你不能把它刪除，它將被碎片收集清除，如果你想清除管理著源文件的對象，你可以調用dispose()函數，雖然C#為它提供了的有效的結構，但是它仍然不象堆棧那樣簡單。

　　在新一代的語言(以前是C++/CLI),你在哪裡建立對象不依賴於你建立對象的種類，你可以堆棧中管理對象，它有確定的解析，但它越界時將被清除，如果你願意你可以在管理堆裡建立對象。

　　這種變化帶來其它的結果，其中最深遠的是你可以把不同的對象放在摸板中或者可以把它看成其它類的成員變量，你可以得到完整的C++生存時間周期，而不是僅僅是把它分配到相應的堆，然後等碎片收集來處理它。

　　解析和定稿

　　當你為其它語言寫了碎片收集對象是，你是否為它寫了解析函數？當你使用C++,你可以在堆棧構造對象，解析函數將運行當它越界時，什麼事情會發生當其他C#或VB程序調用這個對象，運行時僅從簡單的方式去處理，它是用dispose()來解析，任何一個C++/CLI對象都有一個可以任意調用的解析函數。

　　假如你在C#或VB中有dispose()的類，你可能已經寫了一個定論，C++/CLI也有簡便的語法為定論，就象Foo的解析是~Foo,Foo的定論是!Foo(~是比特的not,!是邏輯的not,它們都是提醒是和構造函數對立的),

　　Finalizer將運行當在管理堆中建立而不被調用，確信它所包含的非管理源文件被清除，即使其他調用函數忘了去解析。

　　指針和句柄

　　在C++擴展名管理中，C++的主要限制沒有變化，同樣的符號和語法用做完全的事情，*的含義依賴於你的代碼中的其他位置的信息，你可以試試下面的代碼： Foo* pf = new Foo();
　　Foo對象將在哪裡建立？那塊內存是否被清除？我能象下面那樣對指針做算法嗎：

　　pf++;

　　答案依賴於Foo是否用__gc關鍵字聲明，假如它是碎片收集對象，它只能在管理堆不是在本堆和堆棧中建立，另一方面，如果沒有用__gc聲明，將在本堆中分配內存給它，你必須記得去清除它。

　　如果編譯器有自由去改變語言，就象在C++/CLI上發生的，可以忽視什麼地方生存的什麼類型的類，可以用不同的語法表明它在哪裡生存：

Foo^ hf = gcnew Foo();
　　這被叫做句柄，許多C++團隊好象都是用^符號來標明的，你可以用*和->來解除句柄的引用，你可以從實例的聲明而不是回過頭從類的聲明中得到生命期的聲明。例如：

程序代碼：

ref class R
{
　 private:
　　 int m_a;
　 public:
　　 R(int a): m_a(a) {}
}; 

你可能會認為ref是C++/CLI新的關鍵字，但它不是，“ref class“是關鍵字，你可以有變量是ref而不會引起混亂，其他的關鍵字還有”value class“,”interface class“,”enum class“，幾乎過去所有的C++程序都會有value這個變量，我很高興value沒有變成關鍵字。

　　Ref class 是一個管理類，一個被設計成生存管理隊中和被碎片收集管理的類，象我前面所示的你可以在堆棧中聲明一個實例，編譯器會幫你找到它，加上不可見的智能指針。

　　特性

　　有很多C++特性的改變，因為我是用C++比較笨拙的特性開始的例子，所以我現在關閉比較相近的C++

程序代碼：
ref class R
{
　 private:
　　 int m_Size;
　 public:
　　 property int Size
　　 {
　　　 int get() { return m_Size; }
　　 void set(int val){m_Size = val;}
　 }
};
R r;
r.Size = 42;

property是一個關鍵字嗎？有點象，它是一個位置關鍵字，所以你可以有property的變量和函數，而不會引起混亂，它只會在類定義中有特殊的含義，現在在C++/CLI中有單獨的單元提供特性定義，我很喜歡這樣，相信你也是。