自一个人默默走

关于编辑器，我尝试了很多种，例如 vim, emacs, scite, ultraedit, editplus, emeditor, pspad, notepad++, ... 很可惜的是没有一个能完全满足我的需求。

就说 emeditor 有非常强大的搜索功能吧，而 vim 有非常好的 file type identification 能力，而恰恰两个的强大之处都是对方的薄弱之处。

emeditor 的编辑 control 是使用 text replace 的方式来进行语法高亮的，所以效果不是很理想；而 vim 使用的方法要比之高明得多了。emeditor 强大的搜索功能是通过 regex++ (也就是现在的 boost::regex)来实现的，而 vim 只实现了 posix regular expression。

有一个设想就是自己编写一个 editor，仅限于设想。想像下，为了搬 10kg 的东西，却要先做 100n 的准备活动，这种做法值得吗？

templates 实在是 c++ 中最优秀的思想了，不，应该说 templates 是程序设计中产生的最优美的思想了。

于是就有人想把 c 中安插上 templates，于是就诞生了用 c++ 编译器来编译 c 代码的方法，也产生了 gp。实际在我理解中，扣除 class 等一些特性的话，gp 就是 c 的 pb + templates。

早晨上了 cto 的一堂课，感触颇深——用过程式的语言来实现各种 oop 的设计技法——这也可以理解为什么公司里不过多地使用 c++ boost library 等 template features。

想起我在 n 年前去面试时，我跟一个公司的 cto 说：“用 c 可以实现几乎所有 c++ 的事情”——最后被骂了一顿——现在的 cto 告诉我：“这完全是可行的”。

话题回到 templates 的问题上。cto 早晨说过：“lpc 中的 mixed 类型是非常优秀的，相比之下，c 就没有完善的实现”。所谓的 mixed 就是一种可以放置下所有类型的类型，在 c 中的 void * 我不知道有些什么样的副作用，等春节期间好好地研究下 c。

昨天快下班的时候在和同事谈论“把一个库，例如 sqlite c api 让 lpc 从中调
用”的问题，同事给了一个完整的方案，事后在回家的路上回想，发现其方法非常
繁琐。

晚上回家把问题总结了一下，其实是“把某某库的 api interface 暴露给某种
script vm”的问题。在 lpc 中，实现该过程的行为非常繁琐，而 python 通过
boost:: python 库，是非常简单的，而且 boost:: python 还可以把 python 类
暴露给 c++；今天陪老娘去逛街，回到家开门的一瞬间想到，managed c++ 把其
它非 managed code 暴露给 .net framework 的最好工具，当然，也是把 .net
framework 类、方法等暴露给 unmanaged 的最好工具——同样是双向的。

结论是，有 vm 的 script 一般都存在把非 vm 接口暴露给 vm，或者把 vm 中的
元素接口暴露给非 vm 的方法；script 是一种可以非常方便地组合 system
language (如 c/c++, ada) 等的最好工具；Stroustrup 所说的优先开发库的做
法不适合于 script language。

我在上高中的时候，有一个同学跟我说了，学习的效率在于你知道“是什么”而不用去关心“为什么”——知道“是什么”所花费的时间比知道“为什么”要多许多，而且，即便你知道了“为什么”，你自己去实现一个比已经现有的东西要浪费许多的精力，况且，你不能肯定其是不是稳定的。
为什么这么说呢，从我最近做的项目中，发现了这么些东西——VC6 是不能实现模板类偏特化的，但 boost 实现了(是实现还是用其它什么手法不知道，但是它能达到我要的效果！)，那么好，直接用就好了，无需去了解它是怎么实现的。
当你打算利用一个类的功能时，且它不是设计来被继承的、你也不能自己写一个外包类封装它，那么最好的办法就是写全局函数——感谢 C++，提供了那么强大的能力——在 Java 或者 C# 上，你只能实现 Vistor 模式。这么说是因为：昨天要利用 boost::functionN 来实现从 DLL 中动态加载函数的一些功能，本来打算实现 DLLFuncProxyN 但是碍于 VC6 不能实现模板类偏特化，想继承 boost::functionN 但是它本来就不是设计来被继承的；最好的办法就是写一个模板方法，封装一些功能。
这次生病对我有一个非常大的影响：生病前，因为我的完美主义，我几乎认为自己做出来的东西是最完美的——所以当遇到一个新问题时，我优先考虑自己实现；但生病后，自己清楚的发现，与其自己去实现一个别人已经实现过的东西，还不如直接使用别人已有的(也可能做得更好，比如 boost.config)，而不需要去考虑怎么实现也不用担心自己的实现稳不稳定。简单地说，我以前碰到一个问题时是先考虑自己怎么做，而现在是优先考虑别人是否已经做了，自己拿来用就好了。

今天写代码，频繁地使用 #ifdef _MSC_VER 之类的宏进行编译器鉴别，后来想想，那些东西不是 boost.config 都已经做了吗——而且饱经测试，相当的稳定——那为什么我不直接拿来用呢？于是就开始用了，渐渐地发现，原来 boost.config 不只包含关于编译器的信息，它也包含着关于各种版本标准库、平台等等的信息，完全不需要再自己使用原始的、某种编译器特定的宏去判断了！

可以理解为什么那么多的 C++ 高手们青睐于 .NET Framework——因为长期的 C++ 纷争，造成 C++ 一直没有一个完整的标准库(什么，你说 Standard C++ Library？那个能提供线程、XML、正则、远程调用等等东西吗？)，而 .NET Framework 非常全面，几乎所有需要的库功能都提供了——虽然在 C++ 上可以分别找到实现相同功能的各种库，但是因为不是统一设计，所以它们的风格，编码习惯等等都差别很大。
就说一个 boost 库吧，虽然有很多的功能，但是 boost 的库实在太多了，代码的公共命名看起来基本一致外，各库用各自的编码习惯。
关于 .NET, ACE, VCF, Xerces-C 等库，是在 OO 的基础上加入少量的泛型——这不是什么好的主意，特别对一个 C++ 程序员来说。我现在希望能在网上找到一个完完全全的 Generic Programming 的库。当然，希望它能比 boost 风格更统一。

作为一个团队项目，我只能忍痛割爱，去掉 STLport 的链接——要知道，STLport 和 boost, CppUnit 等等的项目需要很多复杂的设置，而且可能会出现很多意想不到的情况。
现在只能用 vc6 默认的 Plauger STL，我不知道这个标准库究竟可能达到什么程度，也不清楚如何升级这个库。总之有一点是肯定的：不能用这个版本的 STL 做任何关于标准容器的多线程操作。

开始并不知道这有这么复杂，但是命令实在太长了，索性写了一个批处理文件，内容如下：
bjam.exe "-sTOOLS=intel-win32-stlport" "-sINTEL_VERSION=9.1" "-sINTEL_PATH=C:\Program Files\Intel\Compiler\C++\9.1\IA32" "-sSTLPORT_PATH=D:\The_Last_Version_of" "-sSTLPORT_VERSION=5.1" "-sINTEL_BASE_MSVC_TOOLSET=msvc" "-sMSVC_ROOT=C:\Program Files\Microsoft Visual Studio\VC98" "--stagedir=D:\The_Last_Version_of\boost" "-sBUILD=debug release <runtime-link>dynamic <native-wchar_t>on" stage

由于不知道的原因，vc6 + icc91 的环境编译出的从 cvs 下载的 boost 1.35 很多库文件缺失，可能是 boost 库的作者们并不曾使用 vc6 + icc91的环境吧，在 Regression Tests 中只看到 intel-vc8-win-9.1_x86_64, intel-vc8-win-9.1 和 intel-vc71-win-9.1 的测试结果。我不知道他们的机器怎么都那么好，用得起 vc8。早晨只好换 vc71，用其自带的编译器。
当然还是使用 STLport，vc71 的标准库不知道是不是线程安全的，但 STLport 肯定是，我也不开发 managed code 所以可以用这个库。

我犯戒了——大量地使用了盗版的软件——正如我以前说过的，这在国内虽然是普遍现象，但不是滥用盗版的理由。前些天使用 Visual C++ 8.0，才体会到什么叫慢。我不知道 M$ 是怎么想的，但是它有两个非常致命的问题：
1. 慢，慢得惊人，当然我的机器不算非常快，但是如果为了使用一个编译器而换台机器，在有选择的前提下，我不会使用那个东西；
2. 不向下兼容：VC8 是不能直接编译 VC6 的代码(但 VC7.1 可以)；这个决定非常糟糕，现在有很多 VC6 的历史代码，如果需要很大的代价才能编译的话，那么我以及很多人将选择不使用 VC8。
可以说 VC6 非常不标准，也可以说 VC8 非常标准，两种东西相交的结果就是原基于 VC6 开发的项目要经过大量的改造才能在 VC8 上编译(我有个东西改个半天，link 还是出错)；VC8 同时是非常安全的，但是安全是需要代价的，最大的代价就是 VC8 无论编译还是使用起来都非常慢。
综合了许多的考虑，我决定使用 VC6 + ICC9.1 的组合——当然现在使用的是盗版——但如果这个组合能给我带来丰厚收益的话，我会考虑购买正版的。
今天用 ICC 编译一个 VC6 项目，并用 STL/boost 等重构了项目，效果非常好。原来使用 VC6 编译器，一堆的 warning，但是用 ICC 都没了，太爽了！