Re: [資料] 神之物件 (God object, Blob AntiPattern)
: → H45:既然是 uncaught exception, 那麼....仍然需要 unlock 它嗎..? 09/14 20:41
: → H45:這個特例我不太熟，請指教 m(_ _)m 09/14 20:42
當然要呀
你自己的 function uncaught 而已，可能上層有作處理.
其實不止uncaught exception. LockGuard 這玩意也能
令 programmer 的錯失減少，要是要 explicit
unlock 的話，萬一某些程況下漏寫了 Unlock 的話也是
很棘手
寫一個簡單的 LockGuard 例子吧 (以前參考某商業 C++
library 寫的自用 library 大概就是這樣做) :
class MutexLock {
public:
void Lock();
void Unlock();
};
class LockGuard<class T> {
public:
LockGuard<T>::LockGuard<T>(T& lock)
: m_lock(lock) {
m_lock.Lock();
}
LockGuard<T>::~LockGuard<T>() {
m_lock.Unlock();
}
private:
T& m_lock;
};
用的情況:
Foo::bar() {
LockGuard<MutexLock> guard(m_myMutex);
// do whatever u want
// m_myMutex will be unlocked automatically
}
假設 "do whatever u want" 有 exception 發生，或者
裡面 return 了，m_myMutex 也能正確被 unlock.
LockGuard 還有很多變型
比如 UnlockGuard (在特定範圍暫時放開 lock, 範圍完結重新取得)
TryLockGuard (嘗試取得 Lock，失敗的情況當然不會自動做 Unlock 嘍）
還有 ReadLockGuard/WriteLockGuard 這些比較特例的東西.
: 推 wctang:這是很典型的RAII，是C++處理資源的標準做法 09/15 00:29
LockGuard 說是 RAII 好像也不全是，算是有點變奏？
因為一般來說 RAII 通常是在 constructor 取得並 initialize
好 resources. LockGuard 則單純對一個外部的 Mutex (or other
kind of lock) 進行 lock/unlock 而已
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 219.77.26.195
※ 編輯: adrianshum 來自: 219.77.26.195 (09/15 01:37)
推
09/15 10:59, , 1F
09/15 10:59, 1F
推
09/15 13:38, , 2F
09/15 13:38, 2F
推
09/15 14:49, , 3F
09/15 14:49, 3F
→
09/15 14:51, , 4F
09/15 14:51, 4F
→
09/16 00:36, , 5F
09/16 00:36, 5F
→
09/16 00:37, , 6F
09/16 00:37, 6F
→
09/16 00:38, , 7F
09/16 00:38, 7F
→
09/16 00:39, , 8F
09/16 00:39, 8F
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 12 之 19 篇)：