看膩了不著邊際的爭論嗎？我們來寫點程式吧。 要求：請用 C 改寫下列的 C++ 程式，並分析改寫後的效能差異。 (因為我沒寫過 OS，只是設想 OS 可能會需要的功能以及內部可能的 實作方法，謬誤之處請多指教) 1. 檔案操作是大部份 OS 都會提供的功能，我們要實作一個刪除檔案 的 API。不過請注意，檔案可能存在本地端的硬碟上，也可能存在 網路上的某個地方，在 C++ 我們可以用 virtual function 來解 決這個問題： class FileSystem { public: virtual int remove(const char* path) = 0; ... }; class LocalFileSystem : public FileSystem { public: // 打開本地端的硬碟並刪除檔案 virtual int remove(const char* path); ... }; class RemoteFileSystem : public FileSystem { public: // 連線到遠端，發出封包要求刪除檔案 virtual int remove(const char* path); ... }; int remove_file(const char* path){ // fs 可能是本地端也可能是遠端，由 path 決定。 FileSystem& fs = query_file_system(path); // 呼叫 virtual function return fs.remove(path); } 「可是 virtual function 很慢耶！」 是的，所以請用 C 寫一個更快的版本吧！不過請容我提醒，檔案系 統並不是只有 Local 和 Remote 兩種喔，像 Linux 就支援了十幾 種不同的檔案系統，請把這十幾種可能性都考慮進去。 你可以使用 query_file_system(path) 這個 API，也可以自己決定這 個 API 回傳的型別 (看要 enum 或 pointer 都隨你)。 2. 硬體資源通常在同一時間只能給一支 thread 使用，就和兩支程式 同時開檔寫檔，多半會產生問題的道理一樣。因此我們會用 mutex 的方式來避免資源在同一時間被重覆使用。然而資源在利用完成後， 我們必須釋放 mutex 讓下一支 thread 可以繼續使用。在 C++ 中， 我們可以用 RAII 的技巧來達成這個目標。 class Mutex { private: Resource& my_resource; Mutex(const Mutex&); Mutex& operator=(const Mutex&); public: explicit Mutex(Resource& r) : my_resource(r) { lock_resource(r); } ~Mutex() { unlock_resource(my_resource); } }; void SomeClass::operation(Resource& r1, Resource& r2) { Mutex m1(r1); // 鎖住 r1 // 一些對 r1 的操作 ... if(...) // 在某些條件下不需要操作 r2 return; Mutex m2(r2); // 鎖住 r2 // 一些對 r1 和 r2 的操作 ... if(...) // 在某些條件下，不需要更多操作 return; // other_resource 是 SomeClass 的一個成員 // 某些條件下需要操作它 Mutex m3(other_resource); // 一些對 r1, r2 和 other_resource 的操作 ... return; // 終於做完了 = = } 注意這個函式中並不會直接用 unlock_resource 來釋放資源，因 為 Mutex 的 destructor 會在 return 的時候自動被呼叫，而這 也是 C++ 反對者所批評的一點：C++ 插入了 programmer 看不到 的程式碼，所以效能變慢了！ 請用 C 改寫這個例子，不要再用 Mutex 這個 class，直接把 lock_resource 和 unlock_resource 放在真正必要的地方吧。 3. (第三題本來要寫個和 template 相關的，不過愈寫愈長，最後 連我自己都懶得從頭到尾看一次...還是先討論上述兩題吧) --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 59.121.115.112 ※ 編輯: littleshan 來自: 59.121.120.91 (03/08 03:24)