C++11（及现代C++风格）和快速迭代式开发
过去的一年我在微软亚洲研究院做输入法，我们的产品叫“英库拼音输入法” （下载Beta版），如果你用过“英库词典”（现已更名为必应词典），应该知道“英库”这个名字（实际上我们的核心开发团队也有很大一部分来源于英库团队的老成员）。整个项目是微软亚洲研究院的自然语言处理组、互联网搜索与挖掘组和我们创新工程中心，以及微软中国Office商务软件部（MODC）多组合作的结果。至于我们的输入法有哪些创新的feature，以及这些feature背后的种种有趣故事… 本文暂不讨论。虽然整个过程中我也参与了很多feature的设想和设计，但90%的职责还是开发，所以作为client端的核心开发人员之一，我想跟大家分享这一年来在项目中全面使用C++11以及现代C++风格（Elements of Modern C++ Style）来做开发的种种经验。
我们用的开发环境是VS2010 SP1，该版本已经支持了相当多的C++11的特性：lambda表达式，右值引用，auto类型推导，static_assert，decltype，nullptr，exception_ptr等等。C++曾经饱受“学院派”标签的困扰，不过这个标签着实被贴得挺冤，C++11的新feature没有一个是从学院派角度出发来设计的，以上提到的所有这些feature都在我们的项目中得到了适得其所的运用，并且带来了很大的收益。尤其是lambda表达式。
说起来我跟C++也算是有相当大的缘分，03年还在读本科的时候，第一篇发表在程序员上面的文章就是Boost库的源码剖析，那个时候Boost库在国内还真是相当的阳春白雪，至今已经快十年了，Boost库如今已经是写C++代码不可或缺的库，被誉为“准标准库”，C++的TR1基本就脱胎于Boost的一系列子库，而TR2同样也大量从Boost库中取材。之后有好几年，我在CSDN上的博客几乎纯粹是C++的前沿技术文章，包括从06年就开始写的“C++0x漫谈”系列。（后来写技术文章写得少了，也就把博客从CSDN博客独立了出来，便是现在的mindhacks.cn）。自从独立博客了之后我就没有再写过C++相关的文章（不过仍然一直对C++的发展保持了一定的关注），一方面我喜欢关注前沿的进展，写完了Boost源码剖析系列和C++0x漫谈系列之后我觉得这一波的前沿进展从大方面来说也都写得差不多了，所以不想再费时间。另一方面的原因也是我虽然对C++关注较深，但实践经验却始终绝大多数都是“替代经验”，即从别人那儿看来的，并非自己第一手的。而过去一年来深度参与的英库输入法项目弥补了这个缺憾，所以我就决定重新开始写一点C++11的实践经验。算是对努力一年的项目发布第一版的一个小结。
09年入职微软亚洲研究院之后，前两年跟C++基本没沾边，第一个项目倒是用C++的，不过是工作在既有代码基上，时间也相对较短。第二个项目为Bing Image Search用javascript写前端，第三个项目则给Visual Studio 2012写Code Clone Detection，用C#和WPF。直到一年前英库输入法这个项目，是我在研究院的第四个项目了，也是最大的一个，一年来我很开心，因为又回到了C++。
这个项目我们从零开始，，而client端的核心开发人员也很紧凑，只有3个。这个项目有很多特殊之处，对高效的快速迭代开发提出了很大的挑战（研究院所倡导的“以实践为驱动的研究（Deployment-Driven-Research）”要求我们迅速对用户的需求作出响应）：
至于为什么要用C++而不是C呢？对于我们来说理由很现实：时间紧任务重，用C的话需要发明的轮子太多了，C++的抽象层次高，代码量少，bug相对就会更少，现代C++的内存管理完全自动，以至于从头到尾我根本不记得曾遇到过什么内存管理相关的bug，现代C++的错误处理机制也非常适合快速开发的同时不用担心bug乱飞，另外有了C++11的强大支持更是如虎添翼，当然，这一切都必须建立在核心团队必须善用C++的大前提上，而这对于我们这个紧凑的小团队来说这不是问题，因为大家都有较好的C++背景，没有陡峭的学习曲线要爬。（至于C++在大规模团队中各人对C++的掌握良莠不齐的情况下所带来的一些包袱本文也不作讨论，呵呵，语言之争别找我。）
下面就说说我们在这个项目中是如何使用C++11和现代C++风格来开发的，什么是现代C++风格以及它给我们开发带来的好处。
资源管理
说到Native Languages就不得不说资源管理，因为资源管理向来都是Native Languages的一个大问题，其中内存管理又是资源当中的一个大问题，由于堆内存需要手动分配和释放，所以必须确保内存得到释放，对此一般原则是“谁分配谁负责释放”，但即便如此仍然还是经常会导致内存泄漏、野指针等等问题。更不用说这种手动释放给API设计带来的问题（例如Win32 APIWideCharToMultiByte就是一个典型的例子，你需要提供一个缓冲区给它来接收编码转换的结果，但是你又不能确保你的缓冲区足够大，所以就出现了一个两次调用的pattern，第一次给个NULL缓冲区，于是API返回的是所需的缓冲区的大小，根据这个大小分配缓冲区之后再第二次调用它，别提多别扭了）。
托管语言们为了解决这个问题引入了GC，其理念是“内存管理太重要了，不能交给程序员来做”。但GC对于Native开发也常常有它自己的问题。而且另一方面Native界也常常诟病GC，说“内存管理太重要了，不能交给机器来做”。
C++也许是第一个提供了完美折衷的语言（不过这个机制直到C++11的出现才真正达到了易用的程度），即：既不是完全交给机器来做，也不是完全交给程序员来做，而是程序员先在代码中指定怎么做，至于什么时候做，如何确保一定会得到执行，则交由编译器来确定。
首先是C++98提供了语言机制：对象在超出作用域的时候其析构函数会被自动调用。接着，Bjarne Stroustrup在TC++PL里面定义了RAII（Resource Acquisition is Initialization）范式（即：对象构造的时候其所需的资源便应该在构造函数中初始化，而对象析构的时候则释放这些资源）。RAII意味着我们应该用类来封装和管理资源，对于内存管理而言，Boost第一个实现了工业强度的智能指针，如今智能指针（shared_ptr和unique_ptr）已经是C++11的一部分，简单来说有了智能指针意味着你的C++代码基中几乎就不应该出现delete了。
不过，RAII范式虽然很好，但还不足够易用，很多时候我们并不想为了一个CloseHandle, ReleaseDC, GlobalUnlock等等而去大张旗鼓地另写一个类出来，所以这些时候我们往往会因为怕麻烦而直接手动去调这些释放函数，手动调的一个坏处是，如果在资源申请和释放之间发生了异常，那么释放将不会发生，此外，手动释放需要在函数的所有出口处都去调释放函数，万一某天有人修改了代码，加了一处return，而在return之前忘了调释放函数，资源就泄露了。理想情况下我们希望语言能够支持这样的范式：
[我们在招人] 由于我们之前的star intern祁航同学离职去国外读书了，所以再次寻找实习生一枚，参与英库拼音输入法client端的开发，要求如下：
扎实的win32系统底层知识。 扎实的C++功底，对现代C++风格有一定的认识（了解C++11更好）。 理解编写干净、可读、高效的代码的重要性。（最好读过clean code或implementation patterns） 对新技术有热忱，有很强的学习能力；善于沟通，喜欢讨论。
有兴趣的请发简历至liuweipeng@outlook.com。此外，为了节省我们双方的时间，我希望你在发简历的同时回答以下两个问题：
简要介绍一下你在大学里面学习技术的历程，例如看过那些书，经常上那些地方查资料，（如果有）参加过哪些开源项目，（如果有）写过哪些技术文章，等等。 有针对性地对于上面的要求中提到的几点做简要的介绍：例如对win32有哪些了解，C++方面的技术储备，以及对高质量代码的认识，等等。
