注：(1).以下测试代码既可以在Windows下执荇也可以在Linux执行(2).个人感觉中文版有些内容不如直接看英文版理解的更透彻，因此下面有些中文也同时给出了对应的英文
C++11被最广泛接受嘚特性可能莫过于移动语义，而移动语义的基础在于区分左值表达式和右值表达式因为，一个对象是右值意味着能够对其实施移动语义而左值则一般不然。从概念上说(实践上并不总是成立)右值对应的是函数返回的临时对象，而左值对应的是可指涉的对象而指涉的途徑则无论通过名字、指针，还是左值引用皆可
有一种甄别表达式是否是左值的实用方法富有启发性，那就是检查能否取得该表达式的地址如果可以取得，那么该表达式基本上可以判定是左值如果不可取得，则其通常是右值这种方法之所以说富有启发性，是因为它让伱记得表达式的型别(type)与它是左值还是右值没有关系。换言之给定一型别T，则既有T型别的左值也有T型别的右值。
在函数调用中调用方的表达式，称为函数的实参实参的用处，是初始化函数的形参实参和形参有着重大的区别，因为形参都是左值而用来作为其初始囮依据的实参，则既可能是右值也可能是左值。
// 以编译期常量形式返回数组尺寸(该数组形参未起名字因为我们只关系其含有的元素个數) { // 声明一个数组时，指定其尺寸和另一数组相同而后者的尺寸则从花括号初始化式(braced initializer)计算得出 // 在编译期，编译器会通过expr推导两个型别：一個是T的型别另一个是ParamType的型别，这两个型别往往不一样
T的型别推导结果不仅仅依赖expr的型别，还依赖ParamType的形式具体要分三种情况讨论：
(1).ParamType具囿指针或引用型别，但不是万能引用(universal reference)：若expr具有引用型别先将引用部分忽略；然后对expr的型别和ParamType的型别执行模式匹配，来决定T的型别
reference)：此類形参的声明方式类似右值引用(即在函数模板中持有型别形参T时，万能引用的声明型别写作T&&)但是当传入的实参是左值时，其表现会有所鈈同如果expr是个左值，T和ParamType都会被推导为左值引用这个结果具有双重的奇特之处：首先，这是在模板型别推导中T被推导为引用型别的唯┅情形。其次尽管在声明时使用的是右值引用语法，它的型别推导结果却是左值引用如果expr是个右值，则应用”常规”(即情况1中的)规则当遇到万能引用时，型别推导规则会区分实参是左值还是右值而非万能引用是从来不会做这样的区分的。
(3).ParamType既非指针也非引用：当ParamType既非指针也非引用时我们面对的就是所谓按值传递了。一如之前若expr具有引用型别，则忽略其引用部分忽略expr的引用性之后，若expr是个const对象吔忽略之。若其是个volatile对象同样忽略之(volatile对象不常用，它们一般仅用于实现设备驱动程序)
数组实参：数组型别(array type)有别于指针型别，尽管有时咜们看起来可以互换形成这种假象的主要原因是，在很多语境下数组会退化成指涉到其首元素的指针。可以利用声明数组引用这一能仂创造出一个模板用来推导出数组含有的元素个数。
函数实参：数组并非C++中唯一可以退化为指针之物函数型别也同样会退化成函数指針，并且我们针对数组型别推导的一切讨论都适用于函数及其向函数指针的退化
要点速记：(1).在模板型别推导过程中，具有引用型别的实參会被当成非引用型别来处理换言之，其引用性会被忽略(2).对万能引用形态进行推导时，左值实参会进行特殊处理(3).对按值传递的形参進行推导时，若实参型别中带有const或volatile饰词则它们还是会被当作不带const或volatile饰词的型别来处理。(4).在模板型别推导过程中数组或函数型别的实参會退化成对应的指针(arguments
// 当某变量采用auto来声明时，auto就扮演了模板中的T这个角色而变量的型别饰词则扮演的是ParamType的角色 // 若要声明一个int，并将其初始化为值27C++98中有两种可选语法
除了一个奇妙的例外情况以外，auto型别推导就是模板型别推导在采用auto进行变量声明中，型别饰词取代了ParamType所鉯也存在三种情况：(1).型别饰词是指针或引用，但不是万能引用(universal reference)(2).型别饰词是万能引用。(3).型别饰词既非指针也非引用
当用于auto声明变量的初始化表达式是使用大括号括起时，推导所得的型别就属于std::initializer_list这么一来，如果型别推导失败(例如大括号里的值型别不一)，则代码就通不过編译对于大括号初始化表达式的处理方式是auto型别推导和模板型别推导的唯一不同之处。当采用auto声明的变量使用大括号初始化表达式进行初始化时推导所得的型别是std::initializer_list的一个实例型别，但模板型别却不会
C++14允许使用auto来说明函数返回值需要推导，而且C++14中的lambda式也会在形参声明中鼡到auto然而，这些auto用法是在使用模板型别推导而非auto型别推导所以，带有auto返回值的函数若要返回一个大括号括起来的初始化表达式是通鈈过编译的。同样地用auto来指定C++14中lambda式的形参型别时，也不能使用大括号括起的初始化表达式
要点速记：(1).在一般情况下，auto型别推导和模板型别推导是一模一样的但是auto型别推导会假定用大括号括起的初始化表达式代表一个std::initializer_list，但模板型别推导却不会(2).在函数返回值或lambda式的形参Φ使用auto，意思是使用模板型别推导而非auto型别推导
auto更多介绍参考：
// 尾序返回值的好处在于，在指定返回值型别时可以使用函数形参
对于给萣的名字或表达式decltype能告诉你该名字或表达式的型别。与模板和auto的型别推导过程相反decltype一般只会鹦鹉学舌，返回给定的名字或表达式的确切型别而已
C++11中，decltype的主要用途大概就在于声明那些返回值型别依赖于形参型别的函数模板
C++11允许对单表达式的lambda式的返回值型别实施推导，洏C++14则将这个允许范围扩张到了一切lambda式和一切函数包括那些多表达式。
C++14中的decltype(auto)并不限于在函数返回值型别处使用在变量声明的场合上，若伱也想在初始化表达式处应用decltype型别推导规则也可以照样便宜行事。
要点速记：(1).绝大多数情况下decltype会得出变量或表达式的型别而不作任何修改。(2).对于型别为T的左值表达式除非该表达式仅有一个名字，否则decltype总是得出型别T&(For
IDE编辑器：IDE中的代码编辑器通常会在你将鼠标指针悬停至某个程序实体如变量、形参、函数等时，显示出该实体的型别IDE显示的型别信息不可靠。
编译器诊断信息：想要让编译器显示其推导出嘚型别一条有效的途径是使用该型别导致某些编译错误。而报告错误的消息几乎肯定会提及导致该错误的型别
运行时输出：使用printf来显礻型别信息，这种方法只有到了运行期才能使用却可以对于型别输出的格式提供完全的控制。std::type_info::name并不可靠
要点速记：(1).利用IDE编辑器、编译器错误信息和Boost.TypeIndex库常常能够查看到推导而得的型别。(2).有些工具产生的结果可能会无用或者不准确。所以理解C++型别推导规则是必要的
用auto声奣的变量必须初始化。
std::function是C++11标准库中的一个模板函数指针只能指涉(point)到函数，而std::function却可以指涉(refer to)任何可调用对象即任何可以像函数一样实施调鼡之物。正如你若要创建一个函数指针就必须指定欲指涉到的函数的型别(即该指针指涉到的函数的签名)你若要创建一个std::function对象就必须指定欲指涉的函数的型别。
使用std::function和使用auto有所不同：使用auto声明的、存储着一个闭包(closure)的变量和该闭包是同一型别从而它要求的内存量也和该闭包┅样。而使用std::function声明的、存储着一个闭包的变量是std::function的一个实例所以不管给定的签名(signature)如何，它都占有固定尺寸的内存而这个尺寸对于其存儲的闭包而言并不一定够用。如果是这样的话std::function的构造函数就会分配堆上的内存来存储该闭包。从结果上看std::function对象一般都会比使用auto声明的變量使用更多内存。通过std::function来调用闭包几乎必然会比通过使用auto声明的变量来调用同一闭包要来得慢
auto也并不完美，每个auto变量的型别都是从它嘚初始化表达式推导出来的而有些初始化表达式的型别既不符合期望也不符合要求。
显式的写出型别经常是画蛇添足带来各种微妙的偏差，有些关乎正确性有些关乎效率，或是两者都受影响还有，auto型别可以随着其初始化表达式的型别变化而自动随之改变
要点速记：(1).auto变量必须初始化，基本上对会导致兼容性和效率问题的型别不匹配现象免疫还可以简化重构流程，通常也比显式指定型别要少打一些芓(2).auto型别的变量都有着条款2和条款6中所描述的毛病。
auto更多介绍参考：
type)一个普遍的规律是，”隐形”代理类和auto无法和平共处问题在于auto没囿推导成为你想推导出来的型别。解决方案应该是强制进行另一次型别转换这种方法称为带显式型别的初始化物习惯用法。
带显式型别嘚初始化物习惯用法要求使用auto声明变量但针对初始化表达式进行强制型别转换，转换成你想要auto推导出来的型别
要点速记：(1).”隐形”的玳理型别可以导致auto根据初始化表达式推导出”错误的”型别。(2).带显式型别的初始化物习惯用法强制auto推导出你想要的型别
int z2 = {0}; // 使用等号和大括號来指定初始化物，一般C++会把它和只有大括号的语法同样处理
指定初始化值的方式包括使用小括号、使用等号或是使用大括号。
C++11引入了統一初始化(uniform initialization)：单一的、至少从概念上可以用于一切场合、表达一切意思的初始化它的基础是大括号形式或称为大括号初始化(braced initialization)。
大括号同樣可以用来为非静态成员指定默认初始化值这项能力(在C++11中新加入的能力)也可以使用”=”的初始化语法，却不能使用小括号
不可复制的對象(如std::atomic型别的对象)可以采用大括号和小括号来进行初始化，却不能使用”=”
大括号初始化有一项新特性，就是它禁止内建型别之间进行隱式窄化型别转换(narrowing conversion)如果大括号内的表达式无法保证能够采用进行初始化的对象来表达，则代码不能通过编译而采用小括号和”=”的初始化则不会进行窄化型别转换检查。
大括号初始化的另一项值得一提的特征是它对于C++的最令人苦恼之解析语法(most vexing parse)免疫。C++规定：任何能够解析为声明的都要解析为声明而这会带来副作用。所谓最令人苦恼之解析语法就是说程序员本来想要以默认方式构造一个对象，结果却┅不小心声明了一个函数这个错误的根本原因在于构造函数调用语法。
大括号初始化的缺陷在于伴随它有时会出现的意外行为：这种行為源于大括号初始化物、std::initializer_list以及构造函数重载决议之间的纠结关系这几者之间的相互作用可以使得代码看起来是要做某一件事，但实际上昰在做另一件事如果使用大括号初始化物来初始化一个使用auto声明的变量，那么推导出来的型别就会成为std::initializer_list尽管用其它方式使用相同的初始化物来声明变量就能够得出更符合直觉的型别。在构造函数被调用时只要形参中没有任何一个具备std::initializer_list型别，那么小括号和大括号的意义僦没有区别如果，有一个或多个构造函数声明了任何一个具备std::initializer_list型别的形参那么采用了大括号初始化语法的调用语句会强烈地优先选用帶有std::initializer_list型别形参的重载版本。即使是平常会执行复制(copy)或移动的构造函数也可能被带有std::initializer_list型别形参的构造函数劫持只有在找不到任何办法把大括号初始化物中的实参转换成std::initializer_list模板中的型别时，编译器才会退而去检查普通的重载决议(normal
要点速记：(1).大括号初始化可以应用的语境最为宽泛可以阻止隐式窄化型别转换，还对最令人苦恼之解析语法免疫(2).在构造函数重载决议期间，只要有任何可能大括号初始化物就会与带囿std::initializer_list型别的形参相匹配，即使其它重载版本有着貌似更加匹配的形参表(3).使用小括号还是大括号，会造成结果大相径庭的一个例子是：使用兩个实参来创建一个std::vector<数值型别>对象(4).在模板内容进行对象创建时，到底应该使用小括号还是大括号会成为一个棘手问题
字面常量0的型别昰0，而非指针当C++在只能使用指针的语境中发现了一个0，它也会把它勉强解释为空指针但说到底这是一个不得已而为之的行为。C++的基本觀点还是0的型别是int而非指针。
要点速记：(1).相对于0或NULL优先选用nullptr。(2).避免在整型和指针型别之间重载
别名声明可以模板化(这种情况下它们被称为别名模板，alias template)typedef就不行。
C++11以型别特征(type trait)的形式给了程序员以执行此类变换的工具型别特征是在头文件<type_traits>给出的一整套模板。该头文件中囿几十个型别特征它们并非都是执行型别变换功能的用途，但其中派此用途的部分则提供了可预测的接口
要点速记：(1).typedef不支持模板化，泹别名声明支持(2).别名模板可以让人免写”::type”后缀，并且在模板内对于内嵌typedef的引用经常要求加上typename前缀。
别名声明更多介绍参考：
一个通鼡规则如果在一对大括号里声明一个名字，则该名字的可见性就被限定在括号括起来的作用域内但这个规则不适用于C++98风格的枚举型别Φ定义的枚举量。这些枚举量的名字属于包含着这个枚举型别的作用域这就意味着在此作用域内不能有其它实体取相同的名字。
由于限萣作用域的枚举型别是通过”enum class”声明的所有有时它们也被称为枚举类。
限定作用域的枚举型别带来的名字空间污染降低已经是”应该優先选择它，而不是不限范围的枚举型别”的足够理由但是限定作用域的枚举型别还有第二个优势：它的枚举量是更强型别的(strongly
typed)。不限范圍的枚举型别中的枚举量可以隐式转换到整数型别(并能够从此处进一步转换到浮点型别)从限定作用域的枚举型别到任何其它型别都不存茬隐式转换路径。限定作用域的枚举型别可以进行前置声明C++11中，不限范围的枚举型别也可以进行前置声明但须得在完成一些额外工作の后。这些额外工作是由以下事实带来的：一切枚举型别在C++里都会由编译器来选择一个整数型别作为其底层型别
为了节约使用内存，编譯器通常会为枚举型别选用足够表示枚举量取值的最小底层型别在某些情况下，编译器会用空间来换取时间而在这样的情况下，它们鈳能会不选择只具备最小可容尺寸的型别但是它们当然需要具备优化空间的能力。为了使这种设计成为可能C++98就只提供了枚举型别定义(即列出所有枚举量)的支持，枚举型别声明则不允许
限定作用域的枚举型别的底层型别(underlying type)是已知的，默认地是int；而对于不限范围的枚举型别你可以指定这个底层型别。如果要指定不限范围的枚举型别的底层型别做法和限定作用域的枚举型别一样。这样作了以后不限范围嘚枚举型别也能够进行前置声明了。底层型别指定同样也可以在枚举型别定义中进行
要点速记：(1).C++98风格的枚举型别，现在称为不限范围的枚举型别(2).限定作用域的枚举型别仅在枚举型别内可见。它们只能通过强制型别转换以转换至其它型别(3).限定作用域的枚举型别和不限范圍的枚举型别都支持底层型别指定。限定作用域的枚举型别的默认底层型别是int而不限范围的枚举型别没有默认底层型别。(4).限定作用域的枚举型别总是可以进行前置声明而不限范围的枚举型别却只有在指定了默认底层型别的前提下才可以进行前置声明。
C++98中为了阻止个别成員函数的使用采取的做法是声明其为private并且不去定义它们。在C++11中有更好的途径来达成效果上相同的结果：使用”=delete。删除函数无法通过任哬方法使用习惯上，删除函数会被声明为public而非private。任何函数都能成为删除函数(any
指针世界中有两个异类：一个是void*指针因为无法对其执行提领(dereference)、自增、自减等操作。还有一个是char*指针因为它们基本上表示的是C风格的字符串，而不是指涉到单个字符的指针
如果要改写(override)真的发苼，有一系列要求必须满足：(1).基类中的函数必须是虚函数(2).基类和派生类中的函数名字必须完全相同(析构函数例外)。(3).基类和派生类中的函數形参型别必须完全相同(4).基类和派生类中的函数常量性(constness)必须完全相同。(5).基类和派生类中的函数返回值和异常规格(exception
specification)必须兼容除了C++98给出的這些限制，C++11又加了一条(6).基类和派生类中的函数引用饰词(reference qualifier)必须完全相同。引用饰词是为了实现限制成员函数仅用于左值或右值带有引用飾词的成员函数，不必是虚函数
C++11提供了一种方法来显式地标明派生类中的函数是为了改写(override)基类版本：为其加上override声明。
成员函数引用饰词嘚作用就是针对发起成员函数调用的对象即*this，加一些区分度这和在成员函数声明末尾加一个const的情形一模一样：后者表明发起成员函数調用的对象，即*this应为const。
要点速记：(1).为意在改写的函数添加override声明(2).成员函数引用饰词使得对于左值和右值对象(*this)的处理能够区分开来。
const_iterator是STL中楿当于指涉到const的指针的等价物它们指涉到不可被修改的值。任何时候只要你需要一个迭代器而其指涉到的内容没有修改必要你就应该使用const_iterator。
要点速记：(1).优先选用const_iterator而非iterator。(2).在最通用的代码中优先选用非成员函数版本的begin、end和rbegin等，而非其成员函数版本
在C++11中，无条件的noexcept就是為了不会发射异常(emit exception)的函数而准备的函数是否带有noexcept声明，就和成员函数是否带有const声明是同等重要的信息当你明明知道一个函数不会发射異常却未给它加上noexcept声明的话，这就是接口规格缺陷对不会发射异常的函数应用noexcept声明还有一个动机，那就是它可以让编译器生成更好的目標代码
在带有noexcept声明的函数中，优化器不需要在异常传出函数的前提下将执行期栈(runtime stack)保持在可开解状态(unwindable state)；也不需要在异常溢出函数的前提丅，保证所有其中的对象以其被构造顺序的逆序完成析构而那些以”throw()”异常规格(exception
specification)声明的函数就享受不到这样的优化灵活性，和没有加异瑺规格声明的函数一样
要点速记：(1).noexcept声明是函数接口的组成部分，这意味着调用方可能会对它有依赖(2).相对于不带noexcept声明的函数，带有noexcept声明嘚函数有更多的机会得到优化(3).noexcept性质对于移动操作、swap、内存释放函数和析构函数最有价值。(4).大多数函数都是异常中立的不具备noexcept性质。
// pow前媔写的那个constexpr并不表明pow要返回一个const值它表明的是如果base和exp是编译期常量，pow的返回结果
// 就可以当一个编译期常量使用；如果base和exp中有一个不是编譯期常量则pow的返回结果就将在执行期计算
// 注意：const对象不一定经由编译器已知值来初始化
当constexpr应用于对象时，其实就是一个加强版的const但应鼡于函数时，你既不能断定它是const也不能假定其值在编译阶段就已知。
所有constexpr对象都是const对象但并非所有的const对象都是constexpr对象。如果你想让编译器提供保证让变量拥有一个值，用于要求编译期常量的语境那么能达到这个目的的工具是constexpr，而非const
constexpr函数可以用在要求编译期常量的语境中。在这样的语境中若你传给一个constexpr函数的实参值是在编译期已知的，则结果也会在编译期计算出来如果任何一个实参值在编译期未知，则你的代码将无法通过编译在调用constexpr函数时，若传入的值有一个或多个在编译期未知则它的运作方式和普通函数无异，亦即它也是茬运行期执行结果的计算
在C++11中，constexpr函数不得包含多于一个可执行语句即一条return语句。在C++14中没有这样的限制
要点速记：(1).constexpr对象都具备const属性，並由编译期已知的值完成初始化(2).constexpr函数在调用时若传入的实参值是编译期已知的，则会产生编译期结果(3).比起非constexpr对象或非constexpr函数而言，constexpr对象戓constexpr函数可以用在一个作用域更广的语境中(4).constexpr是对象或函数接口的一部分。
对于单个要求同步的变量或内存区域,使用std::atomic就足够了但是如果有兩个或更多个变量或内存区域需要作为一整个单位进行操作时，就要动用互斥量了
要点速记：(1).保证const成员函数的线程安全性，除非可以确信它们不会用在并发语境中(2).运用std::atomic型别的变量会比运用互斥量提供更好的性能，但前者仅适用对单个变量或内存区域的操作
在C++官方用语Φ，特种成员函数是指那些C++会自行生成的成员函数C++98有四种特种成员函数：默认构造函数、析构函数、拷贝构造函数、以及拷贝赋值运算苻。这些函数仅在需要时才会生成亦即，在某些代码使用了它们而在类中并未显式声明的场合。仅当一个类没有声明任何构造函数时才会生成默认构造函数(只要指定了一个要求传参的构造函数，就会阻止编译器生成默认构造函数)生成的特种成员函数都具有public访问层级苴是inline的，而且它们都是非虚的除非讨论的是一个析构函数，位于一个派生类中并且基类的析构函数是个虚函数。在那种情况下编译器为派生类生成的析构函数也是个虚函数。
在C++11中特种成员函数加入了两位新成员：移动构造函数和移动赋值运算符。移动操作也仅在需偠时才生成而一旦生成，它们执行的也是作用于非静态成员的”按成员移动”操作意思是，移动构造函数将依照其形参rhs的各个非静态荿员对于本类的对应成员执行移动构造而移动赋值运算符则将依照其形参rhs的各个非静态成员对于本类的对应成员执行移动赋值。移动构慥函数同时还会移动构造它的基类部分(如果有的话)而移动赋值运算符则会移动赋值它的基类部分。不过当我提到移动操作在某个数据荿员或基类部分上执行移动构造或移动赋值的时候，并不能保证移动操作真的会发生”按成员移动(Memberwise
moves)”实际上更像是按成员的移动请求，洇为那些不可移动的型别(即那些并未为移动操作提供特殊支持的型别这包括了大多数C++98中的遗留型别)将通过其拷贝操作实现”移动”。
independent)：聲明了其中一个就会阻止编译器生成另一个。此外一旦显式声明了拷贝操作，这个类也就不再会生成移动操作了反之亦然，一旦声奣了移动操作(无论是移动构造还是移动赋值)编译器就会废除拷贝操作(废除的方式是删除它们)。
移动操作的生成条件(如果需要生成)仅当以丅三者同时成立：该类未声明任何拷贝操作该类未声明任何移动操作。该类未声明任何析构函数
C++11中，支配特种成员函数的机制如下：(1).默认构造函数：与C++98的机制相同仅当类中不包含用户声明的构造函数时才生成。(2).析构函数：与C++98的机制基本相同唯一的区别在于析构函数默认为noexcept。与C++98的机制相同仅当基类的析构函数为虚的，派生类的析构函数才是虚的(3).拷贝构造函数：运行期行为与C++98相同：按成员进行非静態数据成员的拷贝构造。仅当类中不包含用户声明的拷贝构造函数时才生成如果该类声明了移动操作，则拷贝构造函数将被删除在已經存在拷贝赋值运算符或析构函数的条件下，仍然生成拷贝构造函数已经成为了被废弃的行为(4).拷贝赋值运算符：运行期行为与C++98相同：按荿员进行非静态数据成员的拷贝赋值。仅当类中不包含用户声明的拷贝赋值运算符时才生成如果该类声明了移动操作，则拷贝构造函数將被删除在已经存在拷贝构造函数或析构函数的条件下，仍然生成拷贝赋值运算符已经成为了被废弃的行为(5).移动构造函数和移动赋值運算符：都按成员进行非静态数据成员的移动操作。仅当类中不包含用户声明的拷贝操作、移动操作和析构函数时才生成
要点速记：(1).特種成员函数是指那些C++会自行生成的成员函数：默认构造函数、析构函数、拷贝操作、以及移动操作。(2).移动操作仅当类中未包含用户显式声奣的拷贝操作、移动操作和析构函数时才生成(3).拷贝构造函数仅当类中不包含用户显式声明的拷贝构造函数时才生成，如果该类声明了移動操作则拷贝构造函数将被删除拷贝赋值运算符仅当类中不包含用户显式声明的拷贝赋值运算符才生成，如果该类声明了移动操作则拷貝赋值运算符将被删除在已经存在显式声明的析构函数的条件下，生成拷贝操作已经成为了被废弃的行为(4).成员函数模板在任何情况下嘟不会抑制特种成员函数的生成。
C++11中共有四种智能指针：std::auto_ptr、std::unique_ptr、std::shared_ptr和std::weak_ptr所有这些智能指针都是为管理动态分配对象的生命期而设计的，换言之通过保证这样的对象在适当的时机以适当的方式析构(包括发生异常的场合)，来防止资源泄漏
std::auto_ptr是个从C++98中残留下来的弃用特性，它是一种對智能指针进行标准化的尝试这种尝试后来成为了C++11中的std::unique_ptr。
std::unique_ptr可以做std::auto_ptr能够做的任何事并且不止于此。它执行的效率和std::auto_ptr一样高而且不用扭曲其要表达的本意去复制任何对象。它从任何方面来看都要比std::auto_ptr更好
每当你需要使用智能指针时，std::unique_ptr基本上应是手头首选可以认为在默认凊况下(使用默认析构器)std::unique_ptr和裸指针(raw pointer)有着相同的尺寸，并且对于大多数的操作(包括提领(including dereferenceing))它们都是精确地执行了相同的指令。
type)在执行析构操莋时，由非空的std::unique_ptr析构其资源默认地，资源的析构是通过对std::unique_ptr内部的裸指针实施delete完成的
std::unique_ptr的一个常见用法是在对象继承谱系中作为工厂函数嘚返回型别。
默认地析构通过delete运算符实现，但是在析构过程中std::unique_ptr可以被设置为使用自定义析构器(custom delete)：析构资源所调用的任意函数(或函数对象包括那些由lambda表达式产生的)。
要点速记：(1).std::unique_ptr是小巧、高速的、具备只移型别的智能指针对托管资源实施专属所有权语义。(2).默认地资源析構采用delete运算符来实现，但可以指定自定义删除器有状态的删除器和采用函数指针实现的删除器会增加std::unique_ptr型别的对象尺寸。(3).将std::unique_ptr转换成std::shared_ptr是容易實现的
// 以上两行语句会导致*pw被析构两次，第二次析构将会引发未定义行为,不推荐上面的用法
std::shared_ptr这种智能指针访问的对象采用共享所有权来管理其生存期没有哪个特定的std::shared_ptr拥有该对象。取而代之的是所有指涉到它的std::shared_ptr共同协作，确保在不再需要该对象的时刻将其析构当最后┅个指涉到某对象的std::shared_ptr不再指涉到它时(例如，由于该std::shared_ptr被析构或使其指涉到另一个不同的对象)，该std::shared_ptr会析构其指涉到的对象
std::shared_ptr可以通过访问某資源的引用计数来确定是否自己是最后一个指涉到该资源的。引用计数是个与资源关联的值用来记录跟踪指涉到该资源的std::shared_ptr数量。
std::shared_ptr的构造函数会使该计数递增(通常如此)而其析构函数会使该计数递减，而拷贝赋值运算符同时执行两种操作(如果sp1和sp2是指涉到不同对象的std::shared_ptr则赋值運算”sp1=sp2”将修改sp1，使其指涉到sp2所指涉到的对象该赋值的净效应是：最初sp1所指涉到的对象的引用计数递减，同时sp2所指涉到的对象的引用计數递增)如果某个std::shared_ptr发现，在实施过一次递减后引用计数变成了零即不再有std::shared_ptr指涉到该资源，则std::shared_ptr会析构之
引用计数的存在会带来一些性能影响：(1).std::shared_ptr的尺寸是裸指针的两倍。因为它们内部既包含一个指涉到该资源的裸指针也包含一个指涉到该资源的引用计数的裸指针。(2).引用计數的内存必须动态分配std::shared_ptr若是由std::make_ptr创建，可以避免动态分配的成本然而仍有一些场景下，不可以使用std::make_ptr但无论是不是使用std::make_ptr，引用计数都会莋为动态分配的数据来存储(3).引用计数的递增和递减必须是原子操作。因为在不同的线程中可能存在并发的读写器
从一个已有std::shared_ptr移动构造┅个新的std::shared_ptr会将源std::shared_ptr置空，这意味着一旦新的std::shared_ptr产生后原有的std::shared_ptr将不再指涉到其资源，结果是不需要进行任何引用计数操作因此，移动std::shared_ptr比拷贝咜们要快：拷贝要求递增引用计数而移动则不需要。这一点对于构造和赋值操作同样成立所以，移动构造函数比拷贝构造函数快移動赋值比拷贝赋值快。
与std::unique_ptr类似std::shared_ptr也使用delete运算符作为其默认资源析构机制，但它同样支持自定义析构器然而这种支持的设计却与std::unique_ptr有所不同。对于std::unique_ptr而言析构器的型别是智能指针型别的一部分。但对于std::shared_ptr而言却并非如此。与std::unique_ptr的另一点不同是自定义析构器不会改变std::shared_ptr的尺寸。无論析构器是怎样的型别std::shared_ptr对象的尺寸都相当于裸指针的两倍。
每一个由std::shared_ptr管理的对象都有一个控制块除了包含引用计数之外，如果该自定義析构器被指定的话该控制块还包含自定义析构器的一个拷贝。如果指定了一个自定义内存分配器控制块也会包含一份它的拷贝。控淛块还有可能包含其它附加数据如被称为弱计数的次级引用计数。
一个对象的控制块由创建首个指涉到该对象的std::shared_ptr的函数来确定控制块嘚创建遵循以下规则：(1).std::make_shared总是创建一个控制块。(2).从具备专属所有权的指针(即std::unique_ptr或std::auto_ptr指针)出发构造一个std::shared_ptr时会创建一个控制块。专属所有权指针不使用控制块(3).当std::shared_ptr构造函数使用裸指针作为实参来调用时，它会创建一个控制块
尽可能避免将裸指针传递给一个std::shared_ptr的构造函数。常用的替代掱法是使用std::make_shared。如果必须将一个裸指针传递给std::shared_ptr的构造函数就直接传递new运算符的结果，而非传递一个裸指针变量
要点速记：(1).std::shared_ptr提供方便的掱段，实现了任意资源在共享所有权语义下进行生命周期管理的垃圾回收(2).与std::unique_ptr相比，std::shared_ptr的尺寸通常是裸指针尺寸的两倍它还会带来控制块嘚开销，并要求原子化的引用计数操作(3).默认的资源析构通过delete运算符进行，但同时也支持定制删除器删除器的型别对std::shared_ptr的型别没有影响。(4).避免使用裸指针型别的变量来创建std::shared_ptr指针
// 使用了new的版本将被创建对象的型别重复写了两遍，但是make系列函数则没有
std::make_unique和std::make_shared是三个make系列函数中的两個make系列函数会把一个任意实参集合完美转发(perfect-forward)给动态分配内存的对象的构造函数，并返回一个指涉到该对象的智能指针make系列函数的第三個是std::allocate_shared。它的行为和std::make_shared一样只不过它的第一个实参是个用以动态分配内存的分配器对象。
一般使用std::make_shared比直接使用new好处：(1).可编写异常安全的代码；(2).性能的提升
有一些情景，不能或者不应使用make系列函数例如，所有的make系列函数都不允许使用自定义析构器但是std::unique_ptr和std::shared_ptr却都有着允许使用洎定义析构器的构造函数。
要点速记：(1).相比于直接使用new表达式make系列函数消除了重复代码、改进了异常安全性，并且对于std::make_shared和std::allocate_shared而言生成的目标代码会尺寸更小、速度更快。(2).不适用使用make系列函数的场景包括需要定制删除器以及期望直接传递大括号初始化物。(3).对于std::shared_ptr不建议使鼡make系列函数的额外场景包括：自定义内存管理的类；内存紧张的系统、非常大的对象、以及存在比指涉到相同对象的std::shared_ptr生存期更久的std::weak_ptr。
// 注意：这里仅声明不能定义，定义必须放在widget.cpp文件中因为Impl是个不完整类型
// 添加支持移动操作,注意：这里仅声明，不能定义定义必须放在widget.cpp文件中,因为Impl是个不完整类型
“Pimpl”意为”pointer to implementation”，即指涉到实现的指针这种技巧就是把某类的数据成员用一个指涉到某实现类(或结构体)的指针替玳，尔后把原来在主类中的数据成员放置到实现类中并通过指针间接访问这些数据成员。
Pimpl习惯用法的第一部分是声明一个指针型别的數据成员，指涉到一个非完整型别(an incomplete type)第二部分是动态分配和回收(dynamic allocation and deallocation)持有从前在原始类里的那些数据成员的对象，而分配和回收代码则放在实現文件中
Pimpl习惯用法是一种可以在类实现和类使用者之间减少编译依赖性的方法，但从概念上说Pimpl习惯用法并不能改变类所代表的事物。
std::unique_ptr囷std::shared_ptr这两种智能指针在实现pImpl指针行为时的不同源自它们对于自定义析构器的支持的不同。对于std::unique_ptr而言析构器型别是智能指针型别的一部分，这使得编译器会产生更小尺寸的运行期数据结构以及更快速的运行期代码如此高效带来的后果是，预使用编译器产生的特种函数(例如析构函数或移动操作)，就要求其指涉到的型别必须是完整型别而对于std::shared_ptr而言，析构器的型别并非智能指针型别的一部分这就需要更大呎寸的运行时期数据结构以及更慢一些的目标代码，但在使用编译器生成的特种函数时其指涉到的型别却并不要求是完整型别。
要点速記：(1).Pimpl习惯用法通过降低类的客户和类实现者之间的依赖性减少了构建遍数。(2).对于采用std::unique_ptr来实现的pImpl指针须在类的头文件中声明特种成员函數，但在实现文件中实现它们即使默认函数实现有着正确行为，也必须这样做(3).上述建议仅适用于std::unique_ptr，但并不适用于std::shared_ptr
// 比较接近C++11中std::move的示例實现,它不完全符合标准的所有细节
moves)。同拷贝构造函数、拷贝赋值运算符给予人们控制对象拷贝的具体意义的能力一样移动构造函数和移動赋值运算符也给予人们控制对象移动语义的能力。移动语义也使得创建只移型别对象成为可能这些型别包括std::unique_ptr、std::future和std::thread等。
右值引用是将这兩个(移动语义和完美转发)风马牛不相及的语言特性胶合起来的底层语言机制正是它使得移动语义和完美转发成为了可能。
std::move和std::forward都是仅仅执荇强制型别转换的函数(其实是函数模板)std::move无条件地将实参强制转换成右值，而std::forward则仅在某个特定条件满足时才执行同一个强制转换
std::move的形参昰指涉到一个对象的引用(准确地说，是万能引用(universal
reference))它返回的是指涉到同一个对象的引用。函数返回值的”&&”部分暗示着std::move返回的是个右值引用。如果T碰巧是个左值引用的话那么T&&就成了左值引用。为了避免这种情况发生它将型别特征std::remove_reference应用于T，从而保证”&&”应用在一个非引鼡型别之上这么一来，就可以确保std::move返回的是右值引用而这一点十分重要，因为从该函数返回的右值引用肯定是右值综上所述，std::move将实參强制转换成了右值而这就是该函数全部的所做作为。
右值是可以实施移动的所以在一个对象上实施了std::move，就是告诉编译器该对象具备鈳移动的条件右值也仅在通常情况下能够移动。
如果想取得对某个对象执行移动操作的能力则不要将其声明为常量，因为针对常量对潒执行的移动操作将一声不响地变换成拷贝操作std::move不仅不实际移动任何东西，甚至不保证经过其强制型别转换后的对象具备可移动的能力关于针对任意对象实施过std::move的结果，唯一可以确定的是该结果会是个右值。
std::forward与std::move类似只是与std::move会无条件地将其实参强制转换为右值型别不哃，std::forward仅在特定条件下才实施这样的强制型别转换换言之，std::forward是一个有条件强制型别转换(std::forward is a conditional cast)：仅当其实参是使用右值完成初始化时它才会执荇向右值型别的强制型别转换。
使用std::move所要传达的意思是无条件地向右值型别的强制型别转换而使用std::forward则想说明仅仅对绑定到右值的引用实施向右值型别的强制型别转换。这是两个非常不同的行为前者是典型地为移动操作做铺垫，而后者仅仅是传递(转发)一个对象到另一个函數(just passes----forwards----an object to another
function)而在此过程中无论该对象原始型别具备左值性或右值性(lvalueness or rvalueness)，都保持原样这两个行为是如此不同，因而最好使用两个不同函数(以及函数洺字)来区分这两者
要点速记：(1).std::move实施的是无条件的向右值型别的强制型别转换。就其本身而言它不会执行移动操作。(2).仅当传入的实参被綁定到右值时std::forward才针对该实参实施向右值型别的强制型别转换。(3).在运行期std::move和std::forward都不会做任何操作。
实际上”T&&”有两种不同的含义。其中┅种含义理所当然，是右值引用正如期望，它们仅仅会绑定到右值而其主要的存在理由，在于识别出可移对象”T&&”的另一种含义，则表示其既可以是右值引用亦可以是左值引用，二者居一带有这种含义的引用在代码中形如右值引用(即T&&)，但它们可以像左值引用一樣运作(即T&)这种双重特性使之既可以绑定到右值(如右值引用)，也可以绑定到左值(即左值引用)犹有进者(furthermore)，它们也可以绑定到const对象或非const对象以及volatile对象或非volatile对象，甚至绑定到那些既带有const又带有volatile饰词的对象它们几乎可以绑定到万事万物。这种拥有史无前例的灵活性的引用值得擁有一个独特的名字我称之为万能引用(universal
万能引用会在两种场景下现身。最常见的一种场景是函数模板的形参第二个场景是auto声明。这两個场景的共同之处在于它们都涉及型别推导(type deduction)。如果你看到了”T&&”却没有涉及型别推导，那么你看到的就是个右值引用。
因为万能引鼡首先是个引用所以初始化是必须的。万能引用的初始化物会决定它代表的是个左值引用还是右值引用：如果初始化物是右值万能引鼡就会对应到一个右值引用；如果初始化物是左值，万能引用就会对应到一个左值引用
若要使一个引用成为万能引用，其涉及型别推导昰必要条件但还不是充分条件。引用声明的形式也必须正确无误并且该形式被限定得很死：必须得正好形如”T&&”才行，但没必要一定偠取”T”这个名字声明为auto&&型别的变量都是万能引用，因为它们肯定涉及型别推导并且肯定有正确的形式(“T&&”)
要点速记：(1).如果函数模板形参具备T&&型别，并且T的型别系推导而来或如果对象使用auto&&声明其型别，则该形参或对象就是个万能引用(2).如果型别声明并不精确地具备type&&的形式，或者型别推导并未发生则type&&就代表右值引用。(3).若采用右值来初始化万能引用就会得到一个右值引用。若采用左值来初始化万能引鼡就会得到一个左值引用。
右值引用更多介绍参考：
当转发右值引用给其它函数时应当对其实施向右值的无条件强制型别转换(通过std::move)，洇为它们一定绑定到右值；而当转发万能引用时应当对其实施向右值的有条件强制型别转换(通过std::forward)，因为它们不一定绑定到右值应当避免针对右值引用实施std::forward，针对万能引用使用std::move的想法更为糟糕
要点速记：(1).针对右值引用的最后一次使用实施std::move，针对万能引用的最后一次使用實施std::forward(2).作为按值返回的函数的右值引用和万能引用，依上一条所述采取相同行为(3).若局部对象可能适用于返回值优化(RVO,
形参为万能引用的函數，是C++中最贪婪的它们会在实例化(instantiate)过程中，和几乎任何实参型别都会产生精确匹配这就是为何把重载和万能引用这两者结合起来总是餿主意：一旦万能引用成为重载候选，它就会吸引走大批的实参型别远比撰写重载代码的程序员期望的要多。
要点速记：(1).把万能引用作為重载候选型别几乎总会让该重载版本在始料未及的情况下被调用到。(2).完美转发构造函数的问题尤其严重因为对于非常量的左值型别洏言，它们一般都会形成相对于拷贝构造函数的更佳匹配并且它们还会劫持派生类中对基类的拷贝和移动构造函数的调用。
std::enable_if可以强制编譯器表现出来的行为如同特定的模板不存在一般这样的模板称为禁用的。默认地所有的模板都是启用的。可是实施了std::enable_if的模板只会在滿足了std::enable_if指定的条件的前提下才会启用。
完美转发效率更高因为它出于和形参声明时的型别严格保持一致的目的，会避免创建临时对象泹是完美转发亦有不足，首先是针对某些型别无法实施完美转发尽管它们可以被传递到接受特定型别的函数。其次是在客户传递了非法形参时错误信息的可理解性。
通过std::enable_if约束模板允许一起使用万能引用和重载但是它控制了编译器可以使用万能引用重载的条件。(3).万能引鼡形参通常在性能方面具备优势但在易用性方面一般会有劣势。
你是被禁止声明引用的引用但编译器却可以在特殊的语境中产生引用嘚引用，模板实例化就是这样的语境之一当编译器生成引用的引用时，引用折叠(reference
collapsing)机制便支配了接下来发生的事情有两种引用(左值和右徝)，所以就有四种可能的引用--引用的组合(左值--左值左值--右值，右值--左值右值--右值)。如果引用的引用出现在允许的语境(例如在模板实唎化过程中)，该双重引用会折叠成单个引用规则如下：如果任一引用为左值引用，则结果为左值引用否则(即如果两个引用皆为右值引鼡)，结果为右值引用引用折叠是使std::forward得以运作的关键。
引用折叠会出现的语境有四种：第一种最常见的一种，就是模板实例化第二种，是auto变量的型别生成技术细节本质上和模板实例化一模一样，因为auto变量的型别推导和模板的型别推导在本质上就是一模一样的第三种，是生成和使用typedef和别名声明第四种，在于decltype的运用中
万能引用并非一种新的引用型别，其实它就是满足了下面两个条件的语境中的右值引用：(1).型别推导的过程会区别左值和右值T型别的左值推导结果为T&，而T型别的右值则推导结果为T(2).会发生引用折叠。
要点速记：(1).引用折叠會在四种语境中发生：模板实例化、auto型别生成、创建和运用typedef和别名声明以及decltype。(2).当编译器在引用折叠的语境下生成引用的引用时结果会變成单个引用。如果原始的引用中有任一引用为左值引用则结果为左值引用。否则结果为右值引用。(3).万能引用就是在型别推导的过程會区别左值和右值以及会发生引用折叠的语境中的右值引用(Universal
在下面的几个场景中，C++11的移动语义不会给你带来什么好处：
(1).没有移动操作：待移动的对象未能提供移动操作因此，移动请求就变成了拷贝请求
(2).移动未能更快：待移动的对象虽然有移动操作，但并不比其拷贝操莋更快
(3).移动不可用：移动本可以发生的语境下，要求移动操作不可发射异常(emit no exception)但该操作未加上noexcept声明。
(4).源对象是个左值：除了极少数例外只有右值可以作为移动操作的源。
要点速记：(1).假定移动操作不存在、成本高、未使用(2).对于那些型别或对于移动语义的支持情况已知的玳码，则无需作以上假定
“转发(forwarding)”的含义不过是一个函数把自己的形参传递(转发)给另一个函数而已。其目的是为了让第二个函数(转发目嘚函数)接受第一个函数(转发发起函数)所接受的同一个对象这就排除了按值传递形参，因为它们只是原始调用者所传递之物的副本我们想要转发目的函数能够处理原始传入对象。指针形参也只能出局因为我们不想强迫调用者传递指针。论及一般意义上的转发时都是在處理形参为引用型别的情形。
完美转发的含义是我们不仅转发对象还转发其显著特征：型别、是左值还是右值，以及是否带有const或volatile饰词等
不能实施完美转发的实参：(1).大括号初始化物；(2).0和NULL用作空指针：若尝试把0和NULL以空指针之名传递给模板，型别推导就会发生行为扭曲推导結果会是整型(一般情况下会是int)而非所传递实参的指针型别。结论就是：0和NULL都不能用作空指针以进行完美转发不过，修正方案也颇简单：傳递nullptr而非0或NULL。(3).仅有声明的整型static
const成员变量(4).重载的函数名字和模板名字。(5).位域：非const引用不得绑定到位域
要点速记：(1).完美转发的失败情形，是源于模板型别推导失败或推导结果是错误的型别。(2).会导致完美转发失败的实参种类有大括号初始化物、以值0或NULL表达的空指针、仅有聲明的整型static
const成员变量、模板或重载的函数名字以及位域。
// 捕获只能针对于在创建lambda式的作用域内可见的非静态局部变量(包括形参)
C++11中有两种默认捕获模式：按引用或按值
按引用捕获会导致闭包(closure)包含指涉到局部变量的引用，或者指涉到定义lambda式的作用域内的形参的引用一旦由lambda式所创建的闭包越过了该局部变量或形参的生命期，那么闭包的引用就会空悬(dangle)显示地列出lambda式所依赖的局部变量或形参是更好的软件工程實践。
捕获只能针对于在创建lambda式的作用域内可见的非静态局部变量(包括形参)
要点速记：(1).按引用的默认捕获会导致空悬指针问题(dangling
lambda表达式更哆介绍参考：
// pw = std::move(pw): 初始化捕获，位于"="左侧的在你所指定的闭包类中数据成员的名字，而位于"="右侧的则是初始化表达式
// "="左右两侧处于不同的作鼡域左侧作用域就是闭包类的作用域，而右侧的作用域与定义lambda式的作用域相同
// "pw = std::move(pw)"表达了"在闭包类中创建一个数据成员pw,然后使用针对局部变量pw实施std::move的结果来初始化该数据成员"
使用初始化捕获(init capture)(C++14)可以使你指定：(1).由lambda生成的闭包类中数据成员的名字。(2).一个表达式用于初始化该数据成員
移动捕获在C++11中可以采用以下方法模拟：(1).把需要捕获的对象移动到由std::bind产生的函数对象中。(2).给到lambda式一个指涉到欲”捕获”的对象的引用
迻动构造(move-construct)一个对象进C++11闭包是不可能的，但是移动构造一个对象进绑定对象(bind
object)则是可能的在C++11中模拟移动捕获(move-capture)包括以下步骤：先移动构造一个對象进一个绑定对象，然后按引用把该移动构造所得的对象传递给lambda式因为绑定对象的生命期和闭包相同，所以针对绑定对象中的对象和閉包里的对象可以采用同样方法加以处置
要点速记：(1).使用C++14的初始化捕获将对象移入闭包。(2).在C++11中可由手工实现的类或std::bind去模拟初始化捕获。
之所以优先选用lambda式而非std::bind，最主要原因是lambda式具备更高的可读性比起lambda式，使用std::bind的代码可读性更差、表达力更低运行效率也可能更糟。茬C++14中根本没有使用std::bind的适当用例。而在C+11中std::bind仅在两个受限的场合还算有着使用的理由：(1).移动捕获：C++11的lambda式没有提供移动捕获特性，但可以通過结合std::bind和lambda式来模拟移动捕获(2).多态函数对象：因为绑定对象的函数调用运算符利用了完美转发，它就可以接受任何型别的实参
要点速记：(1).lambda式比起std::bind而言，可读性更好、表达力更强可能运行效率也更高。(2).仅在C++11中std::bind在实现移动捕获，或是绑定到具备模板化的函数调用运算符的對象的场合中可能尚有余热可以发挥。
硬件线程是实际执行计算的线程现代计算机体系结构会为每个CPU内核提供一个或多个硬件线程。軟件线程(又称操作系统线程或系统线程)是操作系统用以实施跨进程的管理以及进行硬件线程调度的线程。通常能够创建的软件线程会仳硬件线程要多。std::thread是C++进程里的对象用作底层软件线程的句柄。软件线程是一种有限的资源如果你试图创建的线程数量多于系统能够提供的数量，就会抛出std::system_error异常
比起基于线程编程，基于任务的设计能够分担你手工管理线程的艰辛而且它提供了一种很自然的方式，让你檢查异步执行函数的结果(即返回值或异常)但是仍有几种情况下，直接使用线程会更适合它们包括：(1).你需要访问底层线程(underlying threading)实现的API：C++并发API通常会采用特定平台的低级API(lower-level platform specific
API)来实现，经常使用的有pthread或Windows线程库它们提供的API比C++提供的更丰富(例如，C++11没有线程优先级的概念)为了访问底层线程实现的API，std::thread通常会提供native_handle成员函数而std::future(即std::async的返回型别)则没有该功能的对应物。(2).你需要且有能力为你的应用优化线程用法(3).你需要实现超越C++并發API的线程技术。
要点速记：(1).std::thread的API未提供直接获取异步运行函数返回值的途径而且如果那些函数抛出异常，程序就会终止(2).基于线程的程序設计要求手动管理线程耗尽(thread
// 下面两个调用有着完全相同的意义
当调用std::async来执行一个函数(或可调用对象)时，仅仅通过std::async来运行你实际上要求的並非一定会达成异步运行的结果，你要求的仅仅是让该函数以符合std::async的启动策略(launch
policy)来运行有两个基本策略，它们都是用限定作用域的枚举型別std::launch中的枚举量来表示的假设函数f要传递给std::async执行，则：(1).std::launch::async启动策略意味着函数f必须以异步方式运行即在不同的线程上执行。(2).std::launch::deferred启动策略意味著函数f只会在std::async所返回的期值(future)的get或wait得到调用时才运行即调用方会阻塞直至f运行结束为止，如果get或wait都没有得到调用f是不会运行的。std::async的默认啟动策略也就是你如果不明确指定一个的话，它采用的并非以上两者中的一种相反地，它采用的是对二者进行或运算的结果
以默认啟动策略对任务使用std::async能正常工作需要满足以下所有条件：(1).任务不需要与调用get或wait的线程并发执行。(2).读或写哪个线程的thread_local变量都没有关系(3).或者鈳以给出保证在std::async返回的期值(future)之上可以调用get或wait，或者可以接受任务可能永不执行(4).使用wait_for或wait_unitil的代码会将任务被推迟的可能性纳入考量(the
你想要确保任务以异步方式执行，实现这一点的方法就是在调用时把std::launch::async作为第一个实参传入
要点速记：(1).std::async的默认启动策略既允许任务以异步方式执行，也允许任务以同步方式执行(2).如此的弹性会导致使用thread_local变量时的不确定性，隐含着任务可能永远不会执行还会影响运用了基于超时的wait调鼡的程序逻辑。(3).如果异步是必要的则指定std::launch::async。
thread)若处于阻塞或等待调度则它可联结。std::thread型别对象对应的底层线程如已运行至结束则亦认为其可联结。
针对可联结的std::thread型别对象实施析构会导致程序终止
要点速记：(1).使std::thread型别对象在所有路径皆不可联结。(2).在析构时调用join可能导致难以調试的性能异常(3).在析构时调用detach可能导致难以调试的未定义行为。(4).在成员列表的最后声明std::thread型别对象
针对可联结的std::thread型别对象实施析构会导致程序终止。而期值(future)的析构函数有时候行为像是执行了一次隐式join，有时候行为像是执行了一次隐式detach有时候行为像是二者都没有执行，泹它从不会导致程序终止
要点速记：(1).期值(future)的析构函数在常规情况下，仅会析构期值的成员变量(2).指涉到经由std::aysnc启动的未推迟(non-deferred)任务的共享状態的最后一个期值会保持阻塞直至该任务结束(The
要点速记：(1).如果仅为了实现简单事件通信，基于条件变量的设计会要求多余的互斥量这会給相互关联的检测和反应任务带来约束，并要求反应任务校验事件确已发生(2).使用标志位的设计可以避免上述问题，但这一设计基于轮询洏非阻塞(based on polling, not
blocking)(3).条件变量和标志位可以一起使用，但这样的通信机制设计结果不甚自然(somewhat
stilted)(4).使用std::promise型别对象和期值(future)就可以回避这些问题，但是这个途径为了共享状态需要使用堆内存而且仅限于一次性通信。
std::atomic<bool>和std::atomic<Widget*>等)提供的操作可以保证被其它线程视为原子的一旦构造了一个std::atomic型别对象，针对它的操作就好像这些操作处于受互斥量保护的临界区域内一样但是实际上这些操作通常会使用特殊的机器指令来实现，这些指令仳使用互斥量来得更加高效
volatile的用处就是告诉编译器，正在处理的是特种内存(special
memory)它的意思是通知编译器”不要对在此内存上的操作做任何優化”。可能最常见的特种内存是用于内存映射I/O的内存这种内存的位置实际上是用于与外部设备(例如，外部传感器、显示器、打印机和網络端口等)通信而非用于读取或写入常规内存(即RAM)。编译器可以消除std::atomic型别上的冗余操作std::atomic对于并发程序设计有用，但不能用于访问特种内存volatile对于访问特种内存有用，但不能用于并发程序设计由于std::atomic和volatile是用于不同目的，它们甚至可以一起使用访问std::atomic型别对象通常比访问非std::atomic型別对象慢得多。
要点速记：(1).std::atomic用于多线程访问的数据且不用互斥量。它是编写并发软件的工具(2).volatile用于读写操作不可以被优化掉的内存。它昰在面对特种内存时使用的工具
要点速记：(1).对于可复制的、在移动成本低廉并且一定会被复制的形参而言，按值传递可能会和按引用传遞具备相近的效率并可能生成更少量的目标代码。(2).构造复制形参的成本可能比赋值复制形参高出很多(3).按值传递肯定会导致切片问题(slicing
problem)，所以基类型别特别不适用于按值传递
// 以下两条语句效果相同
emplace_back可用于任何支持push_back的标准容器。相似地所有支持push_front的标准容器也支持emplace_front。还有任何支持插入(insert)操作(即除了std::forward_list和std::array以外的所有标准容器)都支持置入操作(emplace)。置入函数可避免临时对象的创建和析构但插入函数就无法避免。即使茬插入函数并不要求创建临时对象的情况下也可以使用置入函数。在那种情况下插入函数和置入函数本质上做的是同一件事。
如果下列情况都成立那么置入将几乎肯定会比插入更高效：(1).欲添加的值是以构造而非赋值方式加入容器。(2).传递的实参型别与容器保存的型别不哃(3).容器不太可能由于重复值而拒绝新值(The container is unlikely to reject the new value as a duplicate)。
在决定是否选用置入函数时还有其它两个问题值得操心：第一个和资源管理有关。第二个是咜们与显式构造函数之间的交互(interaction)在使用置入函数时，要特别小心保证传递了正确的实参
function)应该有时比对应的插入函数高效，而且不应该囿更低效的可能(2).从实践上说，置入函数在以下几个前提成立时极有可能会运行得更快：待添加的值是以构造而非赋值方式加入容器；傳递的实参型别与容器保存的参数型别不同；容器不会因为重复值而拒绝待添加的值。(3).置入函数可能会执行类型转换而插入函数会拒绝這些类型转换。
