条款14:在资源管理类中小型coping的行为
2024-09-20 01:39:34
首先假设对于一个mutex互斥器对象,有lock以及unlock两个函数可用:
void lock(Mutex * pm);
void unlock(Mutex * pm);
那么为了防止资源忘记被释放,首先得想法就是创建一个RAII类来进行资源的管理,像下面这样:
class Lock{
explicit Lock(Mutex * mutex)
:mtx(mutex){}
~Lock(){unlock(mtx)}
private:
Mutex * mtx;
};
然后再用户想要使用的时候就应该这样的使用:
func(mutex mtx)
...
{
Lock m1(&mtx);
}
...
这样是可以得,但这里应该注意的一点就是应该阻止用户无疑的对RAII类的coping行为,这个行为在这里不是我们想要的,那么可以做的基本上就是下面这几点
1. 禁止复制:当复制确实不合理的时候就这样做
2. 同样的,对这个RAII类的底层资源也去采用引用计数法:这里就是mtx对象了。可以将它变成shared_ptr成员。
private:
shared_ptr<Mutex> pMtx;
大概就是上面这样,但是这里shared_ptr的删除含义可能不是我们想要的,我们想要在shared_ptr对象析构的时候不是去删除资源,而是去释放对mutex的占用权。
这你就要用到shared_ptr可以自定义的删除器了,删除器在构造的时候直接可以直接的指定。
class Lock{
public:
explicit(Mutex * pm)
:pMutex(pm, unlock)
{lock(pMutex.get());}//这里的get要引起注意啊
private:
shared_ptr<Mutex> pMutex;
};
3.复制底部的资源,就像一般一开始创造自己的string对象做的一样,复制pstring所指向的资源。
4.转移底部资源的拥有权:这个就是auto_ptr所要做的事了,和它的意义正好的相符合的。
小结:
1.复制一个RAII对象就应该一并复制器所管理的资源,所以说资源的coping行为就决定了RAII对象的coping行为(就像上面这个例子中mutex的copy行为决定了他对应的RAII不应该接受拷贝)
2.常见的RAII对象的coping行为是:抑制coping, 使用引用计数法。
小结:
1. APIs一般都要求提供原始资源,所以一般每一个RAII class都应该提供 取得所管理的资源 的方法!
2. 显示转换一般要比隐式转换更好一点,虽然后者较为方便
最新文章
- python 代码片段24
- pageContext对象的用法
- HTML5 CSS3简要教程
- Group 原则
- 机器学习算法库scikit-learn的安装
- cf B. Number Busters
- const中的一些tricky的地方
- SGU 294 He&#39;s Circles
- 微软的OneDrive研究~
- 玩转Linux网络namespace-单机自环測试与策略路由
- exe4教程
- T-SQL编程语句
- Linux 安装依赖库
- 【Python3.6+Django2.0+Xadmin2.0系列教程之二】学生信息管理系统(入门篇)
- 信用卡3D验证相关资料
- JAVA物联网九大核心热点技术
- Java 基础:认识&;理解关键字 native 实战篇
- WPF 绘制曲线图
- BBS项目
- Spring3.x 版本和 JDK1.8 不兼容导致 java.lang.IllegalStateException: Failed to load ApplicationContext