C++/CLI中新推出的自動確定性資源回收（Automatic deterministic destruction）被視 為一個優秀的設計。是使用所謂C++/CLI這個“新瓶”來裝Bjarne Stroustrup提 出的RAII這個“舊酒”。
這的確不錯，相對而言，這個比C#中的using 關鍵字（dispose模式），以及Java中的 hard-coded的dispose方法都要好許多。這個特性是由C++/CLI中棧對象（局部對象）來提供 的，局部對象本身沒錯，RAII也是局部對象應有之義。
但問題在於C++/CLI中棧對象的可用性由於許多原因會大打折扣，使用起來已經遠遠不如 ISO-C++中那樣流暢。下面列出了損傷其可用性的幾大硬傷：
#1、C++/CLI的棧對象並非真的位於棧中
只要類型是ref class，C++/CLI中的棧對象就仍位於托管堆中。仍然使用newobj IL指令 來分配。如果R沒有定義析構器（~R）（注意：C++/CLI中的析構器和C#中的析構器完全兩回 事），那麼下面兩行代碼實際上將生成完全一樣的IL代碼：
R r;
R h=gcnew R;
好像記得Herb Sutter曾經說過他們將來可能會在真正的方法棧中分配r —— 說實話恐怕只有C++背景的人敢這麼“胡思亂想”:) 他們現在只是想在語法層面 讓程序員"感覺"就像r是從棧中分配的一樣。又一個syntax sugar:)
當然為了對稱和語義的完美，有時候還需要在r上應用%——雖然背後仍是什麼 也沒做:)
#2、C++/CLI編譯器默認情況下不會自動產生拷貝構造函數和拷貝賦值操作符
這一點非常令人煩惱，幾乎讓人“望棧對象而卻步”。更糟糕的是BCL中的所 有類型都沒有提供拷貝構造函數和拷貝賦值操作符——因為恐怕只有C++/CLI會用 到他們。
話說回來，即使C++/CLI會自動產生拷貝構造函數和拷貝賦值操作符，那麼繼承自BCL的類 型還是會很麻煩。
#3、如果函數要被其他CLI語言調用，那麼就不能將其參數設計為棧對象
a. static void add(R r){...}
編譯出來有一個modopt元數據，所以可以被其他語言調用，但是如果被其他語言調用，比 如C#，那麼其他語言將是以傳值的方式傳遞引用，而C++/CLI將是傳遞對象拷貝（要調用拷貝 構造器），所以語義混亂，完全不可以這樣做。
b. static void add(R% r){...}
由於編譯出來都有一個modreq元數據，所以不能被其他CLI語言調用。
#4、如果函數要被其他CLI語言調用，那麼也不能將其返回值設計為棧對象
a. static R add(){...}
b. static R% add(){...}
兩者編譯出來都有一個modreq元數據，所以都不能被其他CLI語言調用。
#5。使用BCL時，如果要傳遞棧對象，總要使用“莫名其妙”的%操作符
比如：
String s("abc");
ArrayList list;
list.Add(%s);
實在很不好，還是使用追蹤引用比較好：
String^ s="abc";
ArrayList^ list=gcnew ArrayList();
list->Add(s);
總結一下：
#1和#5對棧對象的可用性影響不算大，畢竟從語義層面來理解，還是行得通的。
但是，#2、#3、#4的影響就很大。#3和#4使得我們必須放棄使用棧對象來進行互操作。而 #2會讓編寫C++/CLI代碼非常的不方便——除非你以後不想使用棧對象。
現在的問題是，是否C++/CLI中的棧對象只是為了獲得自動確定性資源回收而存在？值得 這樣做嗎？
