C++ 提供了 RAII 机制，并提倡使用它来管理各种资源，可是在实际中会发现这一套使用起来并不如想象中的那么方便。在 Linux 下开发会遇到大量 open() / close() 或是 malloc() / free() 类似操作，而且大部分都没有现成好用的 C++ wrapper，如果每组操作都自己去寨一个 class OperationGuard 只用来管理资源释放未免又显得过于繁琐。

其实我需要的只是在退出作用域时自动执行一些清理操作，如果能方便的把要进行的操作封装在一个临时对象的析构函数里就好了。在网上搜索了一下，果然已经有 很多人想到了这个问题，现成的实现有 Boost 的 SCOPE_EXIT，看了一下支持的功能很多，用起来也比想象中复杂了不少。于是还是自己来寨一个好了，也不用很复杂：（以下实现参考了SCOPE(EXIT) IN C++11）

template<class F>
class ScopeExitGuard_Impl{
    F _f;
public:
    ScopeExitGuard_Impl(F f) : _f(f) {}
    ~ScopeExitGuard_Impl(){
        _f();
    }
};
template<class F>
ScopeExitGuard_Impl<F> ScopeExitGuard(F f){
    return ScopeExitGuard_Impl<F>(f);
}

#define SCOPE_EXIT_GUARD(code) \
    auto scope_exit_##__LINE__ = ScopeExitGuard([&]{code;})

C++11 的 lambda 真是好用啊。在 SCOPE(EXIT) IN C++11 那篇中，lambda 使用了 [=] 来获取外部变量，这样一来就只能读取，无法改写。我在上面的 lambda 中改为 [&] 方便改写外部变量。

使用起来很简单：

int a = 1;
{
    SCOPE_EXIT_GUARD(a = 2);
    a = 3;
}
cout << a << endl; // print: 2
{
    int *p = (int*)::operator new(100 * sizeof(int));
    // label 1
    SCOPE_EXIT_GUARD(::operator delete(p));
    for (int i = 0; i < 10; ++i){
        p[i] = i;
    }
}

如果在 ::operator new() 语句或 label 1 处抛出异常，::operator delete() 就不会被调用，因此只需把释放资源的 SCOPE_EXIT_GURAD 语句与申请资源的语句放在一起就好。

前两天在水木 C++ 版看到两个题目，分别是关于指针和 class 的虚函数表的。关于指针和数组，之前已经打过很久的交道了，比较简单。不过虚函数表以及 class 成员的内存布局一直是模模糊糊的概念，趁此机会把《C++对象模型》拿出来研究了一把。

题目一

#include<stdio.h>  
int main()  
{  
    int a[5] = {1, 2, 3, 4, 5};  
    int *ptr = (int*)(&a + 1);    
    printf("%d,%d\n", *(a+1), *(ptr-1));  
} 

输出什么？

数组和指针类型的互相转换，只要弄清楚指针所指地址以及所指的类型就容易分析了：

1. a 的类型是 int[5]，表示一个长度为 5 的 int 型数组
2. 由于 a 的类型是数组，因此对 a 进行算数运算时，其所指地址是以 sizeof(A[0]) 为单位变化的，这里即是 sizeof(int)，因此 *(a+1) 是 a[1]
3. 对 a 取地址，得到的类型是 int (*)[5]，这是一个指针，其指向一个含有 5 个 int 的数组。因此 &a+1 会使地址向后移动 5 个 int 的空间，得到 a[5] 的地址。
4. ptr 是 int* 类型，因此它的算数运算的单位是 sizeof(int)，ptr-1 即可得到 a[4] 的地址。
5. 综上，程序输出 2,5

题目二

#include <iostream>
using namespace std;

class A {
    virtual void g() {
        cout << "A::g" << endl;
    }
private:
    virtual void f() {
        cout << "A::f" << endl;
    }
};

class B : public A {
    void g() {
        cout << "B::g" << endl;
    }
    virtual void h() {
        cout << "B::h" << endl;
    }
};

typedef void(*Fun)(void);

int main() {
    B b;
    Fun pFun;
    for (int i = 0; i < 3; i++) {
        pFun = (Fun)*((int*)* (int*)(&b) + i);
        pFun();
    }
}

输出什么？

看那一串丧心病狂的指针操作！！

class 层次很简单，A 里有两个虚函数 g() 和 f()，B 里重写了 g()，又添了一个 h()。A 里那个 private 是多余，所有函数都是 private 的。 main() 里主要就是对那个函数指针 pFun 赋值，然后调用。看来所有的内容都在那个指针操作里。

1. (&b) 得到 b 的地址，类型是 B*
2. *(int*)(&b) 将 b 的地址按 int 型指针来解释，并取出这个 int 值。相当于将 b 的前 4 个字节 (32位环境下) 当成一个 int 型读出。假设读出的值是 vptr （好吧……其实就是 vptr）
3. *((int*)vptr + i) 将上一个操作取出的值再当成一个地址，并添加 i 个单位偏移。由于是 int* 类型，因此每次偏移一个 sizeof(int) 的空间，即 4 字节。粗略来说就相当于读出 vptr[i] 的值。
4. 最后再转换为 Fun 的函数指针。

用一个图来看一下：

class A 里有两个虚函数，因此它的虚函数表只有两项，分别是 A::g() 和 A::f()。class B 继承自 A，因此它必须首先照搬 A 的虚函数表（前 2 项），然后再添加自己新加的 B::h()，同时在 B 中又重写了 g()，因此 B 的虚函数表里把 A::g() 的位置替换为 B::g()。

根据前面指针的分析可以看出，三次循环分别调用了 B::g(), A::f() 和 B::h()。不过这个调用比较粗暴，完全无视了函数参数。本身类成员函数是带有一个 this 指针做参数的，不过既然这里也没有使用成员变量，因此也就没什么影响了。

以上程序能够成功运行的条件是 class 的虚函数指针位于对象的头部。我试着在 class A 和 class B 中分别添加一个 int 成员，输出结果依然不变（VS2013 和 gcc4.9.2 下），说明这两个编译器都将虚函数指针放在对象头部，没有再试验其他环境，不知道会不会有不同结果。另外，如果是 64位 环境，应将指针变换那一行的所有 int 换成 int64_t 或 long long，不然指针和 int 所占空间不同，地址运算会出错。

很多时候较大数据量的文件 IO 总是成为瓶颈，为了提高效率，有时想要先将文件大块大块的读入再行处理。下面分析两种惯常的处理手法。

1. 将文件一次性读入 string 中。

貌似 std::getline 、 istream::getline 或是 operator<< operator>> 等都不提供一次读到文件结尾的机制，只有 istreambuf_iterator 可以做到：

string 的构造函数前一个参数要多加一层 () 以免编译器误认为是函数声明 = = ...

这样读入 string 会随着内容动态增长，空间不足时会触发额外的 realloc 及 copy 操作，为提高效率有必要预分配足够的空间：

2. 将文件一次性读入 stringstream 中。

filebuf 和 stringbuf 无法直接通过 rdbuf() 重定向，因此从 filebuf 到 stringbuf 需要一次 copy 操作。最简单的方法是直接复制整个 streambuf ：

与 string 的情况相同，这里同样也有一个空间 realloc 及 copy 的问题。但 streambuf 的缓冲区不是那么方便操作的，解决方法是我们给他手动指定一个空间：

最后再顺便 BS 一下 VC 的 STL = =...

虽然 VC 的编译器效率没的说，但被 STL 拖后腿的话不就白搭了嘛。在文件 IO 方面 (fstream) 比起 MinGW (GCC 4.4.0) 带的要慢好几倍。GCC 的 fstream 格式化读写效率与 C 的比已经不分伯仲，以后应该还会有进一步的提升空间 (编译时格式控制 vs 执行时)

另外上面最后一段程序在 VS2008 (VC9.0) 下应该无法得到预想的结果，跟踪进去看了一下，VC 标准库里的 pubsetbuf 函数体居然是空的！内容如下(中间还有一层函数调用)：

看来是等着我们来继承了啊 = = 。而在 MinGW (GCC 4.4.0) 中可以得到预期的结果。

很奇怪的，或者说是一个不应成为问题的问题...
std::list 的 size() 方法时间复杂度是多少？第一感觉应该是 O(1) 没错吧，多一个变量用于储存链表长度应该是很轻易的事情。于是有了下面这段代码：

对两个循环分别计时比较。前一个循环只比后一个多了一句 num += coll.size(); 为了使编译器确实生成 list::size() 的代码。
在 MinGW 5.1.4 中 (GCC 3.4.5) 编译结果运行如下：

可以看到，前一个循环居然比后一个多花了几乎 45 倍的时间...当我把循环次数从 10000 加到 100000 时程序半天没出结果...

由此有理由猜测 std::list 的 size() 方法难道是 O(N) 的？果然，在头文件中发现了这一段：

直接调用 <algorithm> 算法库函数 distance() 计算元素个数……怪不得这么慢。然后又用 VS2008 (VC9.0)编译，结果如下：

奇怪的是前一个循环居然比后一个还快...不过至少知道 VS2008 (VC9.0)里的 size() 应该是 O(1) 的。同样查看了一下代码，如下：

_Mysize 是一个 size_type 类型的变量。疑问解决。不过又有了新问题：

--------------- 咱 -- 是 -- 分 -- 隔 -- 线 ------------------

为什么 GCC 里要把 list::size() 的复杂度搞成 O(N)？

一通搜索后终于看到有这样的讨论：关于 list::splice() 函数。

list 是链表结构，它的优势就在于可以 O(1) 的时间复杂度任意插入删除甚至拼接 list 片段(删除时可能不是，因为要释放内存)，list::splice() 是一个很强大的功能，它可在任意位置拼接两个 list，这正是 list 的优势。如果我们在类内部以一个变量储存 list 的长度，那么 splice() 之后新 list 的长度该如何确定？这是一个很严峻的问题，如果要在拼接操作时计算拼接部分的长度，那么将把 O(1) 的时间变成 O(N)，这么一来 list 相对 vector 的优势就消失殆尽。

面对这个问题，GCC 和 VC 的 STL 库作者们做了不同的选择。GCC 选择舍弃在 list 内部保存元素数量，而在 size() 时直接从头数到尾，这便出现了开头看到的 O(N) 时间才算出 size()；相反，VC 中有了变量 _Mysize ，无论在 insert() erase() splice() 或是 push() pop() 时都需要对其做相应修改。在上面的两个试验中已经看出同样是 10000 个 push_back() 操作，VC 花的时间比较长，不过也仅仅是一个 inc 指令，差别很小就是了。上面几种会改变 list 内容的操作中，大部分对元素数量的影响只是 +1 或 -1，只有 splice() 需要计算拼接部分元素个数，这个差别就大了，咱还是继续用实验证明吧：

首先是 MinGW (GCC 3.4.5) 的结果：

可以看到 10000 次 push 是 10，相对的 20000 次 splice() 几乎没花时间 = =

然后是 VS2008 (VC9.0)：

差别非常明显，花了2秒多才完成。当我把循环次数改成 100000 后 GCC 仍是眨眼间的事，VC 却长时间运行无结果……

怎么说呢，GCC 显然是追求效率至上，尽量体现出 list 的优势所在，不过我觉得这么一来倒不如干脆不提供 list 的 size() 方法，有需求的程序员可以自己维护一个变量记录长度，以免误认为 size() 是 O(1) 的而犯下严重错误。相对的 VC 强调功能性和整体效率，可能在实际中需要对链表一段内容做 splice() 操作的机会远远小于求 size() 的操作，所以舍弃前者而保留后者，不过要维护 _Mysize 其他相关函数中也增加了开销。一个见仁见智的问题，我觉得还是 GCC 的选择比较好，list 的优势应该保留，但能在 size() 函数处给个 warning 什么的就好了。

我想还有一个选择是这样：在 list 内部用一个 bool 变量指示当前内部 size 值是有效还是无效。在通常操作时 bool 保持 true，这样在 size() 时直接返回原值即可；在 splice() 后将此 bool 值置为 false 并不计算长度，直到最后又有需要 size() 时发现 bool 是 false 则从头再来一遍 distance() 并再将 bool 置为 true。暂时只想出这么一个算是折中的方法，基本上都能保持两边 O(1) 的效率，但相应其他各关于元素数量的函数内部都要多一个判断当前 size 值是有效还是无效并选择是否改变其值。反正总是不能非常完美

嘛...本来只是发现 size() 的效率问题，没想到却扯出这么一桩事出来...也算长知识了吧