最近在重构 C++ 代码时突然想起，如果一个基类的虚成员函数被设为 private，有没有意义？又是否合理？
当然，有其一定的意义，那就是不希望子类在其他地方调用父类的这个函数，包括在子类的实现中；如果需要这个功能，应该使用其 public 的接口去使用该功能。而子类可以提供自己的实现，以提供多态。但是，如果子类觉得需要，还可以把这个 private 的虚成员函数重定义成 protected（虽然这会让人迷惑），从而使子类的子类们调用它。
有同学可能会问，如果是一个 private 的纯虚成员函数（语法上当然合理），那语义合理么？嗯，我觉得这的确是个问题——也许是为了告诉写子类的其他同学，这个虚函数，我不希望你们在除了基类已有的接口里调用之外还来用——仅仅是一个道德约束？！
嗯，C++ 就是灵活得过头了，什么都让程序员自己去把控，可是别忘了，“太多的选择比没有选择糟糕得多”。所以，我决定，为了自己也为了别人不犯迷糊，避免使用 private 的虚函数，private 的成员函数仅包含当前类自己使用的函数。
BTW，类的成员变量正好相反，能设为 private 的尽量不要 protected 更不要public，否则后期维护，嗯嗯，就太痛苦了。
根据《Effective STL》条款21中的例子，建立一个比较类型为 less_equal 的 set 容器：
set< int, less_equal<int> > s;
然后连续插入两个10：
s.insert(10); // 10a
s.insert(10); // 10b会得到什么？
在debug下，可能会给出一个assert报比较符号不合法，第二次插入失败，但在release下，这个动作很可能是未定义的，而通常的结果是，set中存在了两个键值同为10的项，也就是说，set被悄声无息地变成了multiset！太可怕了！
所以，为正确的容器挑选正确的比较函数，很重要。用好 STL 其实并不容易，用错了不仅执行效率狂低，而且还可能出现这些难以想象的意外……
Tuesday, March 2, 2010 / Comments Off / Category: Development / Tag: c++
在 C++ 中，有三种类型的循环语句：for、while 和 do...while，但是在一般应用中作循环时，我们可能用 for 和 while 要多一些，do...while 相对不受重视。
但是，最近在读我们项目的代码时，却发现了 do...while 的一些十分聪明的用法，不是用来做循环，而是用作其他来提高代码的健壮性。
[ more... ]
C 中如果创建一个对象失败，就会返回空指针。但是对于 C++ 就不一样了，new 是不应返回空指针的，书上的推荐做法是在构造函数里抛异常。
当不想引入异常机制的时候，一般的做法是在构造器里啥都不做（最多做个变量初始化），加一个 Init() 函数来完成真正的初始化工作。
然而这样就使得每次创建一个对象，都要执行两步（new+init），总不是太方便，其实 C++ 的 new 操作符是带参的，可以通过“new(std::nothrow) CXxx”的方式让 new 失败时返回 null 指针，来标记失败（而不是抛出异常）。
之前只知道在 C++ 的构造器中，调用虚函数（非纯虚函数）不会出现多态的情况，却想当然认为既然析构器可以被声明为虚“函数”，那么析构器应该是能实现虚函数调用的的多态结果的。
事实证明，我又被蒙骗了！
构造器/析构器不会在调用虚函数时执行子类的重载实现，而且更危险的是当构造器/析构器“间接地”调用了虚函数（例如调用了一个非虚函数，但这个函数里调用了虚函数），不仅子类的重载实现不会被执行，而且还很难发现这种 bug。
所以，切记，切忌在构造器/析构器中直接或间接地调用任何虚函数！（单是在构造器/析构器中直接或间接地调用其他对象的虚函数并不受影响）
原本用宏定义包起来的代码类似如下：
#ifndef A
// codes
#endif // A
现在要加入一个宏定义 B，实现类似这样的条件判断（显然实际上这样是不行的）：
其实应该这样：
#if (!defined A) && (defined B)
// codes
#endif // !A && B
这就修正了之前一直以为的“既生 #ifdef，何生 #if defined”的思维，其实还是有差别的。
为了能让编译速度快一点，明智之举是使用前置声明，而不是 #include 整个头文件。
那声明时候可以用前置声明，而什么时候必须 #include 头文件呢？简单的说：
- 当不需要用到类型的具体实现时，包括构造器、赋值运算符、成员函数等，只需要前置声明就可以了
- 当需要用到类型的以上方法时，就不得不 #include 整个头文件
对该技巧的具体分析可以参考这里和这里。
