序言请移步此处
因为这是系列第一篇,所以会带一些功能的 demo,以方便叙述。
首先考虑 shared_ptr
对象的创建,对于给定类型 T
,假设通过
1 | auto ptr = std::make_shared<T>(...); |
创建一个实例。
看一下函数代码:
1 | template<class _Ty, |
这里首先在 heap 上创建了一个 _Ref_count_obj<_Ty>
对象,通过 std::forward()
将 make_shared()
的参数转发作为构造函数;接着通过 default contructor 创建了一个 shared_ptr<_Ty>
,并调用 _Set_ptr_rep_and_enable_shared()
设置相关数据。
因为创建 _Ty
实例需要的参数 _Args
被转发到了 _Ref_count_obj
的构造函数中,且 shared_ptr
的 default constructor 实质上是一个 _constexpr function_,因此猜测 shared_ptr
自身并不负责创建其管理的 object instance,而是将这部分操作“委托”给 _Ref_count_obj
。
单看标准库而言,shared_ptr
/weak_ptr
(后文除特指外,不再同时带上 weak_ptr
) 一开始作为 TR1 的一员引入,低调行事多年后自 C++ 11 开始成为标准库正式成员。
在历史意义上,引入 shared_ptr
不光规范化了 resource ownership 作为 abstraction conception,同时解决了困扰广大 C++ programmers 多年的难题:如何知道一个对象已经被析构了。
前段时间趁着春节,分别基于 IOCP 和 epoll 实现了 demo 级别的 http server(在遵守 http 1.1 socket 复用基础上只提供了某个指定目录下文件的 GET),算是简单的过了一下 proactor 和 reactor 模型下的 TCP 并发服务。
功能做的很粗糙,并且没有封装类似 event-loop 的东西,连接管理也基本算是纸糊的,原因还是前面说过的,只是想过一下两种模型,并且,在不研究当前流行的 paradigm 的前提下,凭借自己的 first understanding / hunch 去实现;等对这块有一段时间的研究后,作为参照,来回对比以加深理解。
周末的时候客服同学反馈有个用户出现了崩溃,并且要来了崩溃 dmp 文件。
挂上 windbg 后发现崩溃原因是 CRT 的 invalid-parameter
异常,第一现场是输出 ffmpeg 的 avcodec 模块的日志。
省略中间若干分析过程,直击结论:FFmpeg 的 Windows 构建并不是用 MSVC 编译的,因此在类似 printf()
函数的 format specifier 使用上出现了偏差。
众所周知,UTF-8 在 Windows 上一直都不是一等公民,在 MSVC 的调试器里,std::string
默认按照本地编码解释,在中文系统上是 GBK 或 GB2312。
于是,如果一个 std::string
或者 char[]
里存储的是 UTF-8 编码的字符串,那么非 ASCII 部分就会乱码。这在调试中是一个非常不好的体验。