Merge pull request #62 from MistEO/master

fix typos

7.The Concurrency API/item37.md

@@ -98,6 +98,7 @@ private:
 - `ThreadRAII`提供了`get`函数访问内部的`std::thread`对象。这类似于标准智能指针提供的`get`函数，可以提供访问原始指针的入口。提供`get`函数避免了`ThreadRAII`复制完整`std::thread`接口的需要，因为着`ThreadRAII`可以在需要`std::thread`上下文的环境中使用
 
 - 在`ThreadRAII`析构函数调用`std::thread`对象t的成员函数之前，检查t是否joinable。这是必须的，因为在unjoinbale的`std::thread`上调用`join or detach`会导致未定义行为。客户端可能会构造一个`std::thread` t，然后通过t构造一个`ThreadRAII`，使用`get`获取t，然后移动t，或者调用`join or detach`，每一个操作都使得t变为unjoinable
+
   如果你担心下面这段代码
 
   ```cpp

7.The Concurrency API/item40.md

@@ -120,7 +120,7 @@ y = x; // read x again
 
 编译器可通过忽略对y的一次赋值来优化代码，因为初始化和赋值是冗余的。
 
-正常内存还有一个特征，就是如果你写入内存没就不会读，再次吸入，第一次写就可以被忽略，因为肯定会被覆盖。给出下面的代码：
+正常内存还有一个特征，就是如果你写入内存没有读取，再次写入，第一次写就可以被忽略，因为肯定会被覆盖。给出下面的代码：
 
 ```cpp
 x = 10; // write x
@@ -143,7 +143,7 @@ auto y = x;
 x = 20;
 ```
 
-可能你会想睡会写这种重复读写的代码（技术上称为redundant loads 和 dead stores），答案是开发者不会直接写，至少我们不希望开发者这样写。但是在编译器执行了模板实例化，内联和一系列重排序优化之后，结果会出现多余的操作和无效存储，所以编译器需要摆脱这样的情况并不少见。
+可能你会想谁会写这种重复读写的代码（技术上称为redundant loads 和 dead stores），答案是开发者不会直接写，至少我们不希望开发者这样写。但是在编译器执行了模板实例化，内联和一系列重排序优化之后，结果会出现多余的操作和无效存储，所以编译器需要摆脱这样的情况并不少见。
 
 这种有话讲仅仅在内存表现正常时有效。“特殊”的内存不行。最常见的“特殊”内存是用来memory-mapped I/O的内存。这种内存实际上是与外围设备（比如外部传感器或者显示器，打印机，网络端口）通信，而不是读写（比如RAM）。这种情况下，再次考虑多余的代码：
 

8.Tweaks/item42.md

@@ -71,7 +71,7 @@ vs.push_back(queenOfDisco); // copy-construct queenOfDisco
 vs.emplace_back(queenOfDisco); // ditto
 ```
 
-因此，emplacement函数可以完成insertion函数的所有功能。并且有时效率更高，至上在理论上，不会更低效。那为什么不在所有场合使用它们？
+因此，emplacement函数可以完成insertion函数的所有功能。并且有时效率更高，至少在理论上，不会更低效。那为什么不在所有场合使用它们？
 
 因为，就像说的那样，理论上，在理论和实际上没有什么区别，但是实际，区别还是有的。在当前标准库的实现下，有些场景，就像预期的那样，emplacement执行性能优于insertion，但是，有些场景反而insertion更快。这种场景不容易描述，因为依赖于传递的参数类型、容器类型、emplacement或insertion的容器位置、容器类型构造器的异常安全性和对于禁止重复值的容器（即`std::set,std::map,std::unorder_set,set::unorder_map`）要添加的值是否已经在容器中。因此，大致的调用建议是：通过benchmakr测试来确定emplacment和insertion哪种更快。