程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> C語言 >> C++ >> 關於C++ >> C++/CLI中棧對象的設計問題

C++/CLI中棧對象的設計問題

編輯:關於C++

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中的棧對象只是為了獲得自動確定性資源回收而存在?值得 這樣做嗎?

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved