这本书写于2001年，在国内这本书已经绝版了，非常可惜。15年后看这本书，我依旧惊叹于 作者的技巧，同时也更加深刻的理解什么叫做你永远都走在精通C++的路上。用火吻的话来 说就是，你什么都不懂。

有人说这本书很鸡肋，因为里面提到的很多东西深度不够的人看不懂，深度够了的人不看也 懂，所以没必要有单独出这样一本书。这种观点的可取之处在于，这本书确实需要一定的深 度才能体会作者的意思。我去年开始学C++，在看过《C++ Primer（评注版）》之后依陈硕 大大的建议买了这本书来看，结果一知半解，读到一半放弃了。那时候我以为是因为这本书 的中文翻译不好，读起来晦涩的缘故。后来我买了一本英文版回来，但是因为上班一直没时 间看，近来早起，抽空看完这本书。现在想来，中文版其实翻译的还是很不错的，作者的行 文风格偏莎士比亚，英文功底不够读起来其实很费劲。

C++ 之父说 C++11 像是一门新的语言，很大一部分得益于标准库在 C++11 中的重要扩充， 而新的智能指针属于其中至关重要的一点。新的智能指针shared_ptr和unique_ptr比起 auto_ptr要好用很多，但是依旧存在一些比较容易踩坑的地方，本文罗列了 stackoverflow 上关于智能指针的一些常见问题。

google 的 cpp style guide 中推荐把头文件保护宏定义成如下格式

1

<PROJECT>_<PATH>_<FILE>_H_

目前大部分的头文件保护宏生成工具都没有办法按照路径来生成这个宏。在 Vim 的 UltiSnips 插件的默认 Snippet 代码中可以使用 once 来生成类似于下面这样的头文件 保护宏：

1

<FILE>_<RANDOM_CHARS>_H

这种默认的行为已经能非常好的避免头文件多重包含问题了，但是从美观性和规范性上来说 ，google 的标准写法略胜一筹。幸运的是 UltiSnips 允许你定义自己的 snippet。本文介 绍一种通过自己编写 snippet 的方式生成符合 google 规范的头文件保护宏。

全文是个人关于注释的观点，很可能有误，不想误人子弟，请慎重考虑其中的任何一个观点 ，欢迎拍砖。

注释不是越多越好

刚开始学编程的时候，总是会有一些老鸟程序员告诉我，优秀的程序员都习惯给自己的代码 加上大量的注释，这一点甚至有很多的老师都是这么教的，以至于有很长一段时间我都对这 个观点深信不疑。

第一个让我这个观点产生怀疑的人是“林纳斯·托瓦兹”，有一段时间疯狂的迷恋操作系统的 内核，而我尝试读一些源码的时候发现，大神们写的代码其实并不会有太多的注释，但是他 们的代码依旧很漂亮。

第二个让我对于注释越多越好的观点产生怀疑的人是C++之父，忘记在他的那一本书中看到 ，注释如果和源码不同步比没有注释更糟糕。

注释是你的源码的一部分，只要你选择写下一行注释，你就需要担负起维护它的责任。我们 经常会在重构一段源码的时候忘记给更改的地方的注释加上相应的修改。最后留给源码的阅 读者无尽的苦恼这段代码怎么就能实现注释里面说的这个功能呢。

这篇文章介绍一种能让 MSVC 使用 MinGW 编译的 C++ 库的方式。（这里只讨论C++库的共 享，MinGW编译出来的C库好像使用可以直接在MSVC中使用的。）

如果你平常使用 Java 语言做开发，当你听到单元测试工具的时候，你很可能马上会想起 JUnit。作为一名C++软件工程师，当我第一次打算给我的程序做单元测试的时候，我的第一 想法是：有这样的工具吗？经过一段时间的搜索之后，我的反应变成了：我该用哪一个？

我在学校的时候，很少听说C++的单元测试工具，以至于我一直认为这样的工具是不存在。 后来慢慢的发现我们可以选择的远比你想象中的要多得多：Catch, Boost.Test, UnitTest++, lest, bandit, igloo, xUnit++, CppTest, CppUnit, CxxTest, cpputest, googletest, cute。

那我们应该使用哪一个呢？如果你在 Google 里面搜索：best c++ unit testing framework。头两条，一条是 stackoverflow 的问答，另一条是 reddit 的问答 。这两个问题都指向同一个单元测试框架：Catch。

自动构建工具由来已久，使用的最为广泛的有两种，GNU 的 autotools 和 llvm 的 cmake 。这篇文章主要对于 autotools 做一个简单的小结，有机会升入学习 cmake 的 话，再补 充。

书籍推荐

这方面的书籍，我只看过一本，Alexandre Duret-Lutz 的《Using GNU Autotools》。严 格来说这不能算是一本书，它是一个PPT，内容非常浅显易懂，推荐给有兴趣深入了解该技 术的人。

最主要对两个工具

autotools 并不是一个软件的名称，它是多个软件对集合，其中最重要对两个软件是 autoconf 和 automake。

我们可以得到什么

通过自动构建工具，我们最终会得到两种东西：config.h 和 Makefile 前者是编译环境相 关的宏定义，而后者是完成软件编译的编译脚本。

如何得到这些这两种文件

这两种文件都是通过固定的模板加上具体的配置得到，config.h 的模板是 config.h.in 而 Makefile 的模板文件是 Makefile.in。而从模板到具体文件输出要做的就是我们熟悉 的 ./configure。

1
2

config.h.in + configure ==> config.h
Makefile.in + configure ==> Makefile

那么这两个模板和 config.h.in 和 Makefile.in 又是如何得来的呢？自动构建的神奇之 处就在于自动生成，而这两个模板文件正是自动生成而来。完成这一操作的命令是 autoreconfig。

autoreconfig

autoreconfig 是一条非常神奇的命令，它是整个 autotools 中最为重要的命令之一 。大 多数的情况下，你只需要简单的 autoreconfig –install 就可以完成大部分的工 作。

当然 autoreconfig 再强大也不可能强大的到无中生有，它依旧需要一些输入，这也就是 需要我们自己编写的两个文件：configure.ac 和 Makefile.am。实际上，configure.ac 这个文件会产生两个输出，configure 和 config.h.in 而 Makefile.am 则会产生 Makefile.am.in

1
2

configure.ac + autoreconfig ==> config.h.in, configure
Makefile.am  + autoreconfig ==> Makefile.in

configure.ac 与 宏

我们写在 configure.ac 里面的东西，大部分都是大写字母，之所以这样写是因为其实其 中的大部分内容都是宏，而宏的命名规范通常都是使用大写字母。

实际上Autoconfig 的核心是 autom4te, 它是 M4 宏处理器的驱动。所以实际上我们 写在 configure.ac 中的宏最终的处理者是 M4，我们可以在 configure.ac 中使用 为M4编写的 宏代码。比如你可以在Autoconfig Archive 下载 ax_cxx_compile_stdcxx_11.m4和 ax_cxx_compile_stdcxx.m4代码，放到项目根目 录下的m4子目录下面，然后在 configure.ac中使用AC_CONFIG_MACRO_DIR([m4])引入该文件。这样就可以在你的 configure.ac 中使用

1

AX_CXX_COMPILE_STDCXX_11()

来检测你的编译器是否支持 C++11，并在支持 C++11 的时候给你的编译器加上类似 -std=c++11 这样的编译选项

使用Linux的一大乐趣在于尝试各种发行版本，所以我总是会不断的重装系统，伴随重载 系统而来的是系统的配置。在日常使用中，我积累了很多装机必备的工具，罗列在下面， 推荐给大家。

这是我自己编写的第一个Vim插件，写这个插件的原因是在编写 C++ 程序的时候，引入 头文件需要离开当前位置，跳到文件头部，找到合适位置插入 #include <xxxx> 这样的 语句，然后返回到原本编辑的位置继续编辑。这是一个重复性非常强的操作，所以我想尝 试编写一个插件来完成这个操作。jetbrains系列的IDE中有一个 Alt-Enter自动引 入头文件的功能，我最终想要实现的效果就是这个样子。

本人平时是 CtrlP 这个插件的重度用户，也知道它可以进行扩展，所以自己参照 ctrlp-funky 中的代码写了这个 ctrlp-header 插件。

目前的功能非常简单，效果图如下：

C++ 文件

C 文件

基本原理

这个插件非常简单，目前的功能非常粗糙，只是从 en.cppreference 中获取标准库中的 头文件列表，提供给 ctrlp，当用户选择了某一个头文件的时候，在当前的 buffer 中 找到合适的位置插入 #include <header_user_selected> 就可以了。

后续工作

这个插件还有很多工作没有完成：

[ ] 支持用户编写的头文件

[ ] 通过记录用户曾经的操作来提供最佳的候选项目

[ ] 支持语义解析，准确的提供头文件