人啊不能想赚进每一分钱，也不要想什么都买到最便宜，否则最后吃亏的一定是你自己。
买贵了就买贵了呗，不就便宜几百块钱么，这点小钱都舍不得还能干啥？
如果想不明白，退票 /退女票 下一题

表示用过，没有什么问题，就是有点简陋

@sbabybird
对 C++来说 virtual 函数是在类对象里面有虚表来确定执行哪个函数的，但是继承过来的对象不修改基类中的虚表，而是附加新的。
继承并不是单纯的按照基类复制成一个新的类，这里是依赖关系所以仍然会保持基类里原有的行为，在基类中实现构造的时候就确定下来的行为是不会改变的。

1、楼主的代码编译都过不了
this 是指针，指针类型不能用.来调用
CHelloA，~CHelloA，~CHello 都只有声明没有定义，link 的时候会 error 的
2、如果正确修改代码
那么最后应该是输出 hello 而不是 hello a

2016 年的美元资产组合不知道是什么东西，猜测是股票，债券，基金之类组合型的产品，在这种产品获得的回报并不是无风险的，拿来和余额宝对比根本就没有可比性。
Lendingclub 楼主自己也说了是 P2P，要比也是和 P2P 类的产品比，依然和余额宝没有可比性。
余额宝纠结是年化 3 还是年化 4 没有什么意义，都是蚊子腿。
美国货币基金盛行的时代已经过去了，限制无风险利率也就是银行存款水平，至于美国银行的存款利率，楼主有兴趣可以查查，大幅度低于国内的。

就找找国内的书看吧，国外的会计书籍对国内也不适用，会计准则不一样，水土不服。

@lun10439547 毕竟都是蚊子肉，小钱没必要太计较。都是差不多的。货币基金之间能有多少差别？为了表面利率来回折腾并不划算，不想存余额宝随便找家其他的货币基金就行了。

那么点利率差别还不够你来回折腾的。
锱铢必较是会吃亏的。

@EterNalReality 后台各种迅雷，P2P 视频软件，或者人家根本就是在挂 PT

为什么不用真实姓名？

@acess
file system filter drivers 有好几种。
微软的文档表示，legacy file system filter drivers can ’ t attach to direct access (DAX) volumes。
我仔细翻阅了一下文档看来是我有点想当然了，File ​ System ​ Filter ​ Drivers 里面要看你把驱动 attach 到什么地方。
如果只把 Filter Device Object Attach 到 File System，那么就只能拦截 IRP_MJ_CREATE 之类的不能拦截 IRP_MJ_WRITE。
如果 Filter Device Object Attach 到 Volume 上，那么就可以拦截 IRP_MJ_CREATE。
File System Minifilter Driver 也是类似的情况，看开发者怎么使用了
我表示没有调试过，IRP_MJ_WRITE 的具体拦截情况，看文档应该是有办法拦的，但是实际上我会觉得拦截 IRP_MJ_CREATE 这样的请求意义不是很大，绝大多数的程序不需要直接进行底层磁盘写入，如果要驱动来判断直接写入扇区是不是应该允许未免是个巨大的工程。一般不需要在这一步进行拦截，如果只是为了防止写入，拦截 IRP_MJ_CREATE 就足够了。

@acess
调用链方面中间有些省略，不过大致上是这样的。
在 ntdll.dll 中 Nt*函数和 Zw*函数功能是相同的, Nt*函数是 Zw*函数的别名.
ntoskrnl.exe 中 ZwCreateFile 会最终调用到 NtCreateFile
在你看到的调用栈里
NtCreateFile 这里使用 IopCreateFile，ObOpenObjectByNameEx 从名字上就能看出来，目的是把名字转换成 Object 对象，在这转换过程中触发了 IRP_MJ_CREATE

只能自己设置小一点的 TTL 减少缓存的时间。
不过依然得等缓存失效才行。

接楼上，做个更正 NtCreateFile 是调用 IoCreateFile，由 IoCreateFile 来发起 IRP 的。这个是我疏忽了。

@acess
应该是可以拦截到的
从调用链就可以看出来。
CreateFileW （\\.\PhysicalDrive0 ）—》 ZwCreateFile->NtCreateFile
NtCreateFile 会向驱动层的最上级驱动发起 IRP_MJ_CREATE，然后 IRP_MJ_CREATE 这个 IRP 会依次按照顺序发送到下级驱动中，直到最后发送到磁盘驱动。
File System Filter Drivers 想拦截拦截文件的打开就一定会在这个调用链中，所以 File System Filter Drivers 有能力拒绝这样的行为。
而对于直接向磁盘写入这种行为来说。
WriteFile-》 ZwWriteFile-》 NtWriteFile
NtWriteFile 产生的 IRP_MJ_WRITE 不会交给 File System Filter Drivers，因为要写入的并不是一个文件系统的对象，所以 File System Filter Drivers 并不会接收到这个 IRP_MJ_WRITE。

@acess
这完全取决于开发者希望产生什么样的效果，比如我要开发一个文件透明加密的驱动，那么我就没有必要防程序直接读取或者写入磁盘的这种行为，因为不会影响到我的程序功能。
一般安全产品在这方面的处理方法也是简单粗暴的，可能有些 HIPS 会直接弹个窗，警告一下，如果允许了剩下的事情 HIPS 也不管。
这个是开发难度与产品功能之间做出的妥协，安全产品当然也可以直接接管更加底层的 IRP 请求，但是那又会面对一堆乱七八糟的问题，比如稳定性方面的问题。

@acess
@ahhui
我解释一下 open \\.\PhysicalDrive0 这种行为。
对于 File System Filter Drivers 来说，open \\.\PhysicalDrive0 这样的行为 Filter Drivers 会收到一个 IRP_MJ_CREATE 的请求，如果 Filter Driver 在针对这个请求直接拒绝，那么直接打开设备的操作明显会失败。这里不存在所谓绕过这么一说。只是取决于驱动怎么处理直接访问设备的请求，如果驱动对此没有拒绝，后续的操作因为直接是针对设备块的读写（其实就是直接向磁盘驱动发起了 IRP ）并不涉及文件系统，所以 File System Filter Drivers 无法拦截后续的读写操作，这看起来就像是，绕过了，但是实际上只是驱动不想粗暴的拒绝而已。
如果要拦截底层的磁盘访问的 IRP 请求当然也是有办法的，不过这又是另外一个话题了。

@RE 不会

@acess 吊销的问题是微软实现方面的问题。这一点我了解的不多，不过微软完全有能力随时发布更新来解决这些问题。
DSE 确实带来了很多问题，也是无可否认的，个人几乎很难在独立开发驱动。不过微软这方面的要求也不是不能理解，因为大多数蓝屏的问题并不是 Windows 自身的问题导致的，几乎都是第三方驱动形成的。在驱动层面开发是很麻烦的事情，普通的 app 如果犯了一个除 0 的错误，也就只是收到一个程序崩溃的提醒，可是驱动层面上那就直接蓝屏了。（其实某种层面上蓝屏是相当好的保护措施）通过 DSE 这样的手段来限制一些开发者这大概才是微软的目的所在。至于未来版本的支持。。内核上很多地方是未公开的，每一个版本都可能会有些许不同，而驱动们为了达到各种各样的目的可能又必须依赖于这些未公开的地方，所以驱动上兼容各种版本是相对比较困难的。微软其实就不想让开发者动内核，什么 hook SSDT 这种事情根本就不是什么正规手段，所以才有了 PatchGuard 这种东西来阻止对内核的修改。