作者adrianshum (Alien)
看板OOAD
标题Re: [资料] 神之物件 (God object, Blob AntiPattern)
时间Sat Sep 15 01:23:58 2007
: → 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)
1F：推 wctang:只要把 lock 视为 resource，很自然的就可以视为 RAII 09/15 10:59
2F：推 H45:写得好，研究中.... 09/15 13:38
3F：推 godfat:那是 RAII 没错 09/15 14:49
4F：→ godfat:所以我会说有些行为是可以视为资源的 09/15 14:51
5F：→ cplusplus:所以说，这种LOCAGUARD，动作都在CTOR里了~ 不是吗 :) 09/16 00:36
6F：→ cplusplus:有些设计可以大大帮助整个程式的架构和安全，WHY NOT? 09/16 00:37
7F：→ cplusplus:当然，是特例，如果一开始所说，只有某些地方适用 09/16 00:38
8F：→ cplusplus:基本上设计CLASS还是很少在CTOR里面做事情 09/16 00:39