自一个人默默走

早晨实现了一个基于 policy 的 class，在有 GC 机制的前提下实现 Policy Pattern 是可行的。问题是用了非常多的动态类型机制，这个东西如果是大应用的话，消耗很大。
因为考虑到在实际的测试中对于创建一个对象的实例可能存在两种情况：直接调用 new 或者通过反射以及类型路径来创建，所以我写了 DirectNewPolicy 和 ReflectCreatePolicy，第二个策略即使不对目标项目进行引用，仍然可以创建目标 Assembly 中的类型，这样可以实现目标项目对测试无知，并且我可以使用同样的方法对 public, protected, private 成员进行同样的测试。

在实践中，使用类自己测试自己，当没有创建自身实例时可行，但是如果创建了，会进入死循环中。不知道别人是不是都碰到了，反正我的程序在 csUnit 中是这样的。

为了保证一致性，我不采用继承的办法来测试 protected 的成员，而是同 private 一样，使用 reflect 方法来测试。在 C# 中，没想到 reflect 异常简单，直接 InvokeMember(...) 就搞定了。

从单元测试的角度出发，我重新写了一个 IPAddress 类。原来的那个是测试在后，而现在这个是测试在前，没想到效果完全不同，产生的代码也基本不同——在完成相同功能的前提下，测试在前的代码相对之更快、更稳定、更简洁……好处太多了！

今天都在使用单元测试，发现集成在 IDE 中的 Test Runner 非常地方便，于是想，如果 C++ 也提供这样的集成测试就好了。
后来分析了下，觉得不太可能：C# Source -compile-> Assembly, Test Runnter -reflect-> Assembly，可以用独立的 Runner 测试 Assembly；而 C++ Source -comipled-> binary，C++ 编译成 binary 的过程中几乎不留下任何 runtime information，程序只有可能自己感知自己，如 CxxTest 的工作原理：CxxTest + C++ Source -generate-> TestUnit.cpp，生成的过程是由一个 perl 脚本完成的，然后使用某种编译器编译 TestUnit.cpp 生成 .exe 并运行，才最终给出测试结果。
CxxTest for eclipse 的插件只是隐藏了生成测试代码、编译、运行等步骤，事实上，它们还是要经历的。

看了些关于 Vim 的文章，心情不能平静。关于 Vim 我现在面临着两大问题：
1. 不能集成 GDB 调试；更几乎没听说过集成 DDD；
2. 不能进行 C++ 重构；连最基本的 Java/C# 重构都没找到资料。
关于集成调试器的，Emacs 做得很好，但是我不觉得 Emacs 会比 Vim 更快捷。但是如果 Emacs 也支持 C++ 重构，那么我可能花精力去学习 Emacs。

非常遗憾，从 Ubuntu 上运行 Windows 失败！一方面是 Xen 对 Windows 并不完全支持；另外则是我现在机器的配置不行——用 Wine 跑 IE 就惨不忍睹了。没法，最终还是要装上 Windows XP。

现在的打算是：用 .NET Framework 开发程序，但同时进行 C++ 的研究，计划是开发一个基于 native code 的 managed C++，享有 GC 等高级功能，但是不失 native C++ 本身的速度。研究 C# 的 reflect 机制，估计会让我在 C++ 的反射方面有所突破吧。

现在头疼的是选择一个 C++ IDE。用 Visual C++ 或许不错，但是我想基于 GCC 进行开发，这个问题还要思考一下。