item24中markdown源代码中第35行的val2应当是var2

第二种情况是auto声明符，它是从以上示例中拿出的：

auto&& val2 = var1;                 //var2是一个通用引用

感谢无私的奉献者们！

在京东上看到，似乎已经有出版社出版了 Effective Modern C++ 了

链接：京东

代码部分保留原文 会好些

在ThreadRAII的实例代码下提到：

这份代码中，我们选择在ThreadRAII的析构函数中异步执行join的动作

~ThreadRAII() { if (t.joinable()) { if (action == DtorAction::join) { t.join(); } else { t.detach(); } } }

此处析构函数并非异步吧？
如果传入DtorAction为join，主线程应该会被ThreadRAII的析构阻塞，直到线程任务return。

有三处重载 应该修改为重写

1. Item 12:使⽤override声明重载函数
2. 条款12：使⽤override声明重载函数
3. 记住：
   为重载函数加上override

"This chapter is largely devoted to common practices in C++98 that have been superseded by better practices in C++11."

这句话两种翻译：
1.本节主要致力于讨论C ++ 98中的常见实践，这些实践已被C ++ 11中的更好的实践所取代。
2.本节主要致力于讨论C++98被C++11中更好的实践所取代的那些常见实践。

那种更好呢？个人感觉delete这节应该主要讨论的是C++11的东西，如果采用翻译1，则感觉像是在讨论C++98。

原文是：const void* 和 const char*

现在如果使用void*和char*调用processPointer就是无效的，按常理说const void*和const void*也应该无效，所以这些实例也应该标注delete:

cnblog 上 boydfd 翻译到 Item27了，
http://www.cnblogs.com/boydfd/category/753605.html
不知道你们能否相互参考一下，哈哈

条款17 请记住 第三条 拷贝构造函数仅当类没有显式声明拷贝构造函数时才自动生成，并且如果用户声明了移动操作，拷贝构造就是delete。拷贝赋值运算符仅当类没有显式声明拷贝赋值运算符时才自动生成，并且如果用户声明了移动操作，拷贝赋值运算符就是delete。当用户声明了析构函数，拷贝操作的自动生成已被废弃。

最后一句，当用户声明了析构函数，拷贝操作的自动生成已被废弃。

拷贝操作是不是应该改为移动操作。

RT

Effective Modern C++11_14.pdf

当然了，非常感谢大佬们的无私奉献。但是确实不少地方好像是机器翻译的，按照英文的思维来翻译。对新手很难。

item40.md内的一个链接未能正确建立

如下代码块所示，item4063行的超链接未填充内容，应填充为https://github.com/kelthuzadx/EffectiveModernCppChinese/blob/master/7.TheConcurrencyAPI/item39.md

RMW操作不是仅有的`std::atomic`在并发中有效而`volatile`无效的例子。假定一个任务计算第二个任务需要的一个重要的值。当第一个任务完成计算，必须传递给第二个任务。[Item39]()表明一种使用`std::atomic<bool>`的方法来使第一个任务通知第二个任务计算完成。计算值的任务的代码如下：

The first letter should not be capital. The sequence of files in chapter 5 is incorrect. 🙃

#26 31已经完成

src: https://github.com/CnTransGroup/EffectiveModernCppChinese/blob/master/src/3.MovingToModernCpp/item11.md?plain=1#L96

针对该函数关于传入右值的使用解释

class Widget {                                  //方法3：传值
public:
    void addName(std::string newName)
    { names.push_back(std::move(newName)); }
    …
};

按值传递：无论传递左值还是右值，都必须构造newName形参。如果传递的是左值，...，如果传递的是右值，需要移动的开销。在函数的实现中，newName总是采用移动的方式到Widget::names。开销总结：左值...，右值实参两次移动。对比...。

如：Widget::addName(string("123"))，应该是直接初始化一次(string("123"))，移动构造函数一次(std::move(newName)->push_back)，而不是右值实参两次移动。

示例引用中注释部分：

Widget w4{10, 5.0};     //使用花括号初始化，但是现在
                        //调用std::initializer_list版本构造函数
                        //(10 和 true 转化为long double)

应为：

Widget w4{10, 5.0};     //使用花括号初始化，但是现在
                        //调用std::initializer_list版本构造函数
                        //(10 和 5.0 转化为long double)

item3.md内的一个链接未能正确建立

如下代码块所示，item24116行的超链接未填充内容，应填充为https://github.com/kelthuzadx/EffectiveModernCppChinese/blob/master/5.RRefMovSemPerfForw/item24.md

要想支持这样使用`authAndAccess`我们就得修改一下当前的声明使得它支持左值和右值。重载是一个不错的选择（一个函数重载声明为左值引用，另一个声明为右值引用），但是我们就不得不维护两个重载函数。另一个方法是使`authAndAccess`的引用可以绑定左值和右值，[Item24]()解释了那正是通用引用能做的，所以我们这里可以使用通用引用进行声明：

原文： The last two examples

src: https://github.com/CnTransGroup/EffectiveModernCppChinese/blob/master/src/2.Auto/item5.md?plain=1#L131

原文：

译文：

这里的翻译好像是错的。

原文的意思应该是
使用了这种声明形式， auto是要使用类型推导规则去推导他的类型的。更准确的说是编译器会从函数的实现去推导出函数的返回类型。

{简单的说就是， auto 是要使用函数 的实现，通过类型推导规则推导出函数的返回类型}

而译文，给出了相返的意思。“不推导类型”，应该是错误 的，

加入自动 生成pdf 的功能
或 管理员帮忙定期release pdf版。

ps:电子的看起来真是没感觉 ，还是感觉 拿 在手里比较踏实。

应该是 虽然deleted函数不能被使用，但它们还是存在于你的程序中。

最后的 "Things to Remember" 第一条:
std::shared_ptr为任意共享所有权的资源**提供**一种自动垃圾回收的便捷方式

auto x1 = 27; //类型是int，值是27
auto x2(27); //同上
auto x3 = { 27 }; //类型是std::initializer_list，
//值是{ 27 }
auto x4{ 27 }; //同上

当gcc编译器大于5.0，auto x4{ 27 }; x4的类型是int 而不是initialized_list

比起使用非限域枚举，限域有很多可圈可点的地方，它避免命名空间污染，防止不经意间使用隐式转换。 （下面这句我没看懂，保留原文。。（是什么典故吗。。。）） In many cases, you may decide that typing a few extra characters is a reasonable price to pay for the ability to avoid the pitfalls of an enum technology that dates to a time when the state of the art in digital telecommunications was the 2400-baud modem.

这句话暴露了Scott的年龄。

这句话的意思就是：
大多数情况下，你应该会觉得多敲几个（几行）字符作为避免使用未限域枚举这种老得和2400波特率猫同时代技术的代价是值得的。

这里想请教一下，ParamType不是通用引用类型吗，是原版这样说的，还是后来加上的。在第一个item里面的一段文字

看错了验证条件

item34 "其中第四个形参了音量" 应该为 "其中第四个形参指定了音量"

Item17多处对于 deprecated 这个词的翻译存在问题。一般会将其译为“过时的”，即当前标准仍支持，但是以后可能将其废弃（停止支持），而不是带着 is 将 is deprecated 译为“被废弃”。希望可以纠正这个小小的问题。

占个坑

typedef std::vector<int>::iterator IterT; 	// typetypedef
std::vector<int>::const_iterator ConstIterT; // defs

应改成

typedef std::vector<int>::iterator IterT;       // type-
std::vector<int>::const_iterator ConstIterT; // defs

发现中文合集都是去年1月的事情了，这中间的修改还挺多的，所以希望管理员可以重新上传一份中文整合？因为我并不知道具体格式（中文或者字体啥的问题？）所以并不好个人制作一份commit上去。

boost库官网是 https://boost.org，文章里的.com是食品网站

logAndAdd(petName); //跟之前一样，拷贝右值到multiset
应该是
logAndAdd(petName); //跟之前一样，拷贝左值到multiset

std::make_unique和std::make_shared是三个make函数中的两个：接收任意的多参数集合，完美转发到构造函数去动态分配一个对象，然后返回这个指向这个对象的指针。第三个make函数是std::allocate_shared。它行为和std::make_shared一样，只不过第一个参数是用来动态分配内存的allocator对象。

其中"make函数"被显示为**make函数**，没有加粗。

==========原文==========
给定我们的目标函数f和转发函数fwd，如果f使用某特定实参做一件事，但是fwd使用相同的实参做另一件事，完美转发就会失败：

f( expression ); //如果这个做某件事，
fwd( expression ); //但是这个做另外的某件事，fwd完美转发expression给f会失败
导致这种失败的实参种类有很多。知道它们是什么以及如何解决它们很重要，因此让我们来看看无法做到完美转发的实参类型。
============应该改为=============
给定我们的目标函数f和转发函数fwd，如果f使用某特定实参会执行某个操作，但是fwd使用相同的实参会执行不同的操作，完美转发就会失败

我已经阅读完了英文版的《Modern Effective C++》，有些晦涩难懂的地方希望找人交流，同时也有意愿共同翻译。
如果你有兴趣的话，我可以来翻译本书的一部分条款。

markdown阅读起来还是比较繁琐，尤其是目录置顶的设计对于快速跳转不是很友好。想请问下是否会有计划将项目部署在类似gitbook之类阅读体验比较友好的平台上。

英文原版靠近结尾的部分：

The 0 passed in the call to lockAndCall was intended to represent a null pointer, but what actually got passed was a run-of-the-mill int.

run-of-the-mill意为“普通的，常规的，平平无奇的”，而不是译文中的“相差十万八千里”。

已经翻译了一半了

std::remove_const::type // 从T中产出const T -----应为从const T产生T
std::remove_reference::type // 从T中产出T&和T&& ----应为重T&和T&&产生T
std::add_lvalue_reference::type // 从T&中产出T ---应为从T产生T&

item1一开始，如下图

红框中，改为：
ParamType是一个通用引用
更好一些。

根据原文：

Declarations introduce names and types without giving details

names 在后续的翻译中应该是 变量名，直译为名字不太合适。

src: https://github.com/CnTransGroup/EffectiveModernCppChinese/blob/master/src/1.DeducingTypes/item3.md?plain=1#L176

1 原文的两行注释合起来是一句话

意为：没有声明std::initializer_list的构造函数

2 此外条款7有一处把parse翻译成“决议”很不合适

原文的用词和句法都很确切易懂，作为译者应尽量保持这种风格，而不是刻意使用“决议”这类看似高级实则有害的词汇。

添加“高深莫测”的意味只会降低翻译质量。

3 又一处错误

红框内是多余的，导致注释无法理解：

4 没有区分括号和花括号

条款7的目标就是区分brace和parens，然而译文的“括号”既用于指代brace，又指代parens。造成混淆。

5 注释的翻译错误过多，必须对照原文才能理解

看起来译者并未读懂原文，也不理解各个例子的代码……