瘦身前后——兼谈语言进化
By 刘未鹏(pongba)
C++的罗浮宫(http://blog.csdn.net/pongba)
《C++0x漫谈》系列导言
这个系列其实早就想写了，断断续续关注C++0x也大约有两年余了，其间看着各个重要proposals一路review过来：rvalue-references，concepts，memory-model，variadic-templates，template-aliases，auto/decltype，GC，initializer-lists…
总的来说C++09跟C++98相比的变化是极其重大的。这个变化体现在三个方面，一个是形式上的变化，即在编码形式层面的支持，也就是对应我们所谓的编程范式(paradigm)。C++09不会引入新的编程范式，但在对泛型编程（GP）这个范式的支持上会得到质的提高：concepts，variadic-templates，auto/decltype，template-aliases，initializer-lists皆属于这类特性。另一个是内在的变化，即并非代码组织表达方面的，memory-model，GC属于这一类。最后一个是既有形式又有内在的，r-value references属于这类。
这个系列如果能够写下去，会陆续将C++09的新特性介绍出来。鉴于已经有许多牛人写了很多很好的tutor（这里，这里，还有C++标准主页上的一些introductive的proposals，如这里，此外C++社群中老当益壮的Lawrence Crowl也在google做了非常漂亮的talk）。所以我就不作重复劳动了 
，我会尽量从一个宏观的层面，如特性引入的动机，特性引入过程中经历的修改，特性本身的最具代表性的使用场景，特性对编程范式的影响等方面进行介绍。至于细节，大家可以见每篇介绍末尾的延伸阅读。
瘦身前后——兼谈语言进化
前一阵子写了一篇文章，提到语言进化的职责之一，就是去除语言中的tricks（职责之二是去除非本质复杂性）。
常看我blog的朋友肯定记得我曾写过的boost源码剖析系列。本来这个系列是打算成书的，但随着对C++的认识发生了一些转变，对语言级技术的热衷逐渐消退，再回过头来看boost库中的一些组件，发现原本觉得很有写的必要的东西顿时消失了。Scott Meyers的主页上也列有一个写Boost Under The Hood的计划，一直也不见成文，兴许也有类似的原因。
一门语言应该是“Make simple things simple, make complex things possible”的。当我们用语言来表达思想的时候，这门语言应该能够提供这样的能力：即让我们能够最直接地表达我们的意思，多一分则太多，少一分则太少，好比古人形容美女：增一分则太肥，减一分则太瘦。
这个问题上，有一个我认为是广泛的误解，就是“KISS便意味着要精简语言，并避免在编码中使用‘高阶’语言特性”。对此有一句话我觉得说得好：你不能通过从一门语言中去掉东西来增加表达力。高阶特性是一面利刃，用得不好固然伤了自己，但这并不表明就没有用。任何东西都是在它真正适用的地方适用，霸王硬上弓的话弓断弦崩反而伤及自身。所以，仅仅因为高阶特性容易误用（而且高阶特性的确也容易吸引人去用且容易误用，不过这是另一个问题），就断然在任何地方都不用并宣称这样才是KISS的话，便因噎废食了。举个例子，高阶函数是有用的，如果在真正需要高阶函数的地方不用高阶函数，那不是KISS，只能让解决方案（或者更确切地说，workaround）更复杂。lambda函数是有用的，但如果在真正需要lambda的地方不使用lambda，也只能导致更复杂更不直观的workarounds。OOP是有用的，但如果你的程序本来就只是简单的“数据+操作”你偏要硬上OOP的话，不仅多了编码时间，而且还降低程序的可见度和可维护性，后者就意味着项目的money。拿C++来说，这是一个广为诟病的问题。C++的偏向底层的应用领域决定了有不少地方使用C++其实就是“数据+操作”，然而很多人却因为用的是C++编译器，便忍不住去使用高级特性，结果把本来简单的事情复杂化——我自己就有不少次这样的经历：用了一大堆类之后，做完了回过头来再看，这些类都干嘛来着？需要吗？最关键的就是要清楚自己做的是什么事情，以及什么工具才是对你所做的事情最适合的。
说到这里不妨顺便说说另一个误解：“如果我反正用不着C++里面的高级特性，那还不如用C罢了”，鉴于C/C++的应用领域，的确有不少地方是可以用C++的C部分完成得很好的，所以这个误解被传播得还是蛮广泛的。这里的一个微妙的忽视在于：用C的话，你就用不到许多很好的C++库了。用C++的话，你完全可以在你自己的编码中不使用高阶特性（说实话，这需要清醒的头脑和丰富的经验，以及克制能力），但你还是可以利用众多的C++库来简化你的工作的：如果一个transform明明可以搞定的你偏要写一个for出来难道能叫KISS？如果一个vector就能避免绝大多数内存管理漏洞和简化内存管理工作你偏偏要手动malloc/free那能叫KISS（我见过不少用C++编码却到处都是malloc/free的）？如果最直接的方式是gc你偏偏要绕一大堆弯子才能保证正确释放那也不叫KISS（等C++09吧）。如果一个for_each(readdir_sequence(".", readdir_sequence::files), ::remove);能搞定的你偏要写：
// in C
DIR* dir = opendir(".");
if(NULL != dir)
{
struct dirent* de;
for(; NULL != (de = readdir(dir)); )
{
struct stat st;
if( 0 == stat(de->d_name, &st) &&
S_IFREG == (st.st_mode & S_IFMT))
{
remove(de->d_name);
}
}
closedir(dir);
}
那能叫KISS？
总之还是那句话：明确知道你想要表达的是什么并用最简洁（在不损害容易理解性的前提下）的方式去表达它。但我认为，最KISS不代表最原始。
进化——两个例子
先举一个平易近人的例子（Walter Bright——D语言发明者——曾在他的一个presentation中使用这个例子），如果我们想要遍历一个数组，在C里面我们是这么做（或者用指针，不过指针有指针自己的问题）：
int arr[10];
… // initialize arr
for(int i = 0; i
{
int value = arr[i];
…
printf
}
这个貌似简单的循环其实有几个主要的问题：
1. 下标索引不应该是int，而应该是size_t，int未必能足够存放一个数组的下标。
2. value的类型依赖于arr内元素的类型，违反DRY，如果arr的类型改变为long或unsigned，就可能发生截断。
3. 这种for只能对数组工作，如果是另一个自定义容器就不行了。
在现代C++里面，则是这么做：
for(std::vector
iter = v.begin();
iter != v.end();
++iter) {
…
}
其实最大的问题就是一天三遍的写，麻烦。for循环的这个问题上篇讲auto的时候也提到。
Walter Bright然后就把D里面支持的foreach拿出来对比（当然，支持foreach的语言太多了，这也说明了这个结构的高效性）。
foreach(i; v) {
…
}
不多不少，刚好表