正文
可靠的软件需要垃圾回收机制。
不是的，GC有时会阻碍可靠性的达成。GC并不能消除所有的内存泄漏，不能解决非内存资源的管理问题。泄漏套接口、文件句柄、线程和锁，可能比内存泄漏更容易让系统停止。支持可靠性的最好办法是，找到应对资源管理和错误处理的方法，比如C++提供的RAII (Resource Aquisition Is Initialization, 资源获取即初始化)。我目前正在研究这种方法，为资源安全和类型安全的C++提供一套全面的系统：Http://www.stroustrup.com/resource-model.pdf 。核心观点是保证没有泄漏，使垃圾收集器没有必要存在。在不影响程序员用代码简单、直接地表达想法的前提下，保证没有泄漏确实很难，但不是没有可能。
为了提高效率，必须编写低级代码。
不是的，现代C++十分擅长低级优化和不同抽象层次间的优化，多少数量的代码都无法跟这种能力相比，特别是现代架构具有深度缓存层次结构和配有大幅度指令调序的优化器的情况下。从更高的层面说，人类无法通过直接使用线程和锁，得到最优化的结果，所以我们需要更高级的模型和算法，获得正确性、可靠性、可预测性和原始性能。当关于机器、数据或算法的一些观点被证明是毫无根据的时候，摆弄bit、byte和指针这些基础会变得可悲。举个列子，看一下我和别人合著的这篇文章（http://www.stroustrup.com/improving_garcia_stroustrup_2015.pdf ）。文章通过去掉精心设计的优化，提高了spec-mark程序的性能。最后生成的程序变得更精简、更清洁、易于维护、可扩展，而且没有副作用。关于零开销抽象（zero-headed abstraction）的问题，我已经谈了很多。最近，我还看到了很多负开销抽象（negative-headed abstraction）的示例：通过简化适当的抽象获得最优化程序。
C++只适合大型复杂的程序。
不是的，除非你认为一两页代码的量就算是大型、复杂的项目。要知道，任何有影响的程序都需要用到一个或更多个库。这适用于每一种语言。不用任何库，单凭光秃秃的语言，对于编程人员来讲是痛苦的也是徒劳的。
在讨论C++或是（更糟地）下定结论时，随随便便地坚持某种谬见，不加思考，只能说明懒惰。之前，我也写了一篇澄清这些谬见的文章：www.stroustrup.com/Myths-final.pdf 。
C++并非静止不前的。标准委员会很快就将宣布C++17的新增特征。您认为哪些特征是值得期待的？
C++17新增了很多小的改进，对于每一个程序员来说都值得期待，但不要指望特别重大或是颠覆性的改进出现。预计在2017标准发布后，这些新增特征随即可以在所有主要的编译器里应用。事实上，大多数C++17的特征已经能用了。
新增特征不一定对所有人有帮助，大多是为了特定群体的需要而完善C++或是标准库的。你可以在搜索引擎里输入C++找到新增特征的详细列表，不过，我会在这里简要谈几点我所喜欢的特征：
mapint,string>mymap; //...
auto[iter,success]=mymap.insert(value); if (success)f(*iter);
对于
map
，
insert()
返回
pair
::iterator,bool>
，现在我们可以命名两个返回值并直接使用，而不用创建一个pair对象，再访问它的成员。
对于循环控制，这一点特别有用：
for(const auto&[key,value]:mymap)
coutkey”value\n’;
variantint,double>v; //可以是int或是double
v=12; auto i=get(v); //i 变成了12
auto d=get(v); //会抛出bad_variant_access异常
count
可以保证输出
g(y)
的值之前先输出
f(x)
的值。在C++17之前，
f(x)
和
g(y)
是可以交错的，这容易产生bug和混乱。
到2020年，我们将看到进行了重大改进的C++20。例如，
这并不是科幻小说里的幻想，很多特征已经开始在某些领域应用了。问题是，ISO C++标准委员会能否通过。
