下一代visual studio版本（以前whidbey,現(xiàn)在是visual studio 2005）提供更加豐富的改進(jìn)的庫文件和沒有很多幕后精簡和加速的壓力，它的大量配合的工具和新的功能將使開發(fā)者的開發(fā)過程變得簡單有趣，對(duì)我而言，這些與visual studio 2005對(duì)C++的處理相比就顯得有些蒼白，這里我主要談?wù)勗谙乱淮鷙isual studio中C++的變化.

跟下劃線拜拜

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

這是一種解決方法：微軟發(fā)現(xiàn)了一種方法不改變編程語言的改變，但是會(huì)出現(xiàn)下面一些結(jié)果：

·開發(fā)者發(fā)現(xiàn)語法不自然
·不能被完全的采用

如例，適當(dāng)?shù)腃++處理方法：
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
};?

　　有良好習(xí)慣的程序員把get和put放在每個(gè)擴(kuò)展名的右面，把潛在的變量放在旁邊，但是編程語言沒要求你這樣做。它提供無環(huán)境支持定界結(jié)構(gòu)讓你明白作為一個(gè)單元是正確的，所以它是不自然的跟其它visual studio .NET語言不一樣。但是你如何去處理這個(gè)問題那，唯一的方式完成C++轉(zhuǎn)換成CLR反之就要改變C++.假如你想那樣做，你可以有足夠的自由得到自然一流的語言會(huì)給你最好的，你可以取消大量的帶雙劃線的關(guān)鍵字。
生存時(shí)間和范圍

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

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

　　下面是在原始的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; } }

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

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

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

　　當(dāng)對(duì)象在管理堆里時(shí)，你不能把它刪除，它將被碎片收集清除，如果你想清除管理著源文件的對(duì)象，你可以調(diào)用dispose()函數(shù)，雖然C#為它提供了的有效的結(jié)構(gòu)，但是它仍然不象堆棧那樣簡單。

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

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

　　解析和定稿

　　當(dāng)你為其它語言寫了碎片收集對(duì)象是，你是否為它寫了解析函數(shù)？當(dāng)你使用C++,你可以在堆棧構(gòu)造對(duì)象，解析函數(shù)將運(yùn)行當(dāng)它越界時(shí)，什么事情會(huì)發(fā)生當(dāng)其他C#或VB程序調(diào)用這個(gè)對(duì)象，運(yùn)行時(shí)僅從簡單的方式去處理，它是用dispose()來解析，任何一個(gè)C++/CLI對(duì)象都有一個(gè)可以任意調(diào)用的解析函數(shù)。

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

　　Finalizer將運(yùn)行當(dāng)在管理堆中建立而不被調(diào)用，確信它所包含的非管理源文件被清除，即使其他調(diào)用函數(shù)忘了去解析。

　　指針和句柄

　　在C++擴(kuò)展名管理中，C++的主要限制沒有變化，同樣的符號(hào)和語法用做完全的事情，*的含義依賴于你的代碼中的其他位置的信息，你可以試試下面的代碼：

Foo* pf = new Foo();

　　Foo對(duì)象將在哪里建立？那塊內(nèi)存是否被清除？我能象下面那樣對(duì)指針做算法嗎：

　　pf++;

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

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

Foo^ hf = gcnew Foo();

　　這被叫做句柄，許多C++團(tuán)隊(duì)好象都是用^符號(hào)來標(biāo)明的，你可以用*和->來解除句柄的引用，你可以從實(shí)例的聲明而不是回過頭從類的聲明中得到生命期的聲明。例如：

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

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

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

　　特性

　　有很多C++特性的改變，因?yàn)槲沂怯肅++比較笨拙的特性開始的例子，所以我現(xiàn)在關(guān)閉比較相近的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是一個(gè)關(guān)鍵字嗎？有點(diǎn)象，它是一個(gè)位置關(guān)鍵字，所以你可以有property的變量和函數(shù)，而不會(huì)引起混亂，它只會(huì)在類定義中有特殊的含義，現(xiàn)在在C++/CLI中有單獨(dú)的單元提供特性定義，我很喜歡這樣，相信你也是。

轉(zhuǎn)載于:https://www.cnblogs.com/flying_bat/archive/2004/11/02/59653.html

總結(jié)

以上是生活随笔為你收集整理的Visual Studio 2005中C++的变化的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。