EffectiveModernC++

目录

• 1 Deducing Types
• 2 auto
• 3 Moving to Modern C++
• 4 Smart Pointers
• 5 Rvalue References, Move Semantics, and Perfect Forwarding
• 6 Lambda Expressions
• 7 The Concurrency API
• 8 Tweaks

---

1. Deducing Types

1. 理解模板类型参数推导
    1. reference-ness忽略
     2. universal reference：T&&
     3. 数组类型：T (&)[N]
     4. 推导by-value参数时，const和volatile被忽略
2. 理解auto类型推导
    1. auto x3 = { 27 }; //x3类型是std::initializer_list<int>（对auto，要求元素须是相同类型），不是int
    2. initializer常量不能用于void f(T param);的模板参数类型推导，但声明为void f(std::initializer_list<T>)可以
    3. C++14允许函数返回值类型的推导，用的是template type deduction，不是auto type deduction

3. 理解decltype
    1. bool f(const Widget& w); // decltype(w) is const Widget&, decltype(f) is bool(const Widget&)
        1. 注意，函数类型的写法（ReturnType(ArgsType)）之前似乎没见过，好像是后来流行的？
    2. 主要用途：声明依赖于函数参数的返回值类型
        1. auto f(Container& c, Index i) -> decltype(c[i]) { ... }
            1. 完善为 -> decltype(std::forward<Container>(c)[i])
        2. 但operator[]可能对std::vector<bool>特化模板容易出问题
    3. C++14 decltype(auto)：可以正确处理引用类型的推导（因为decltype对左值类型总是返回T&）
            1. decltype(auto) f(Container&& c, Index i) { ...return std::forward<Container>(c)[i]; }
    4. 对int x=0; decltype(x)得到int，decltype((x))返回int&

4. 怎样在IDE里查看编译器推导的类型

---

2. auto

1. 优先使用auto
    1. std::function比auto慢？（总感觉这是编译器优化的问题）
    2. v.size()是std::vector<int>::size_type类型（unsigned），使用auto可避免这个记忆负担？
    3. for (const auto& p : m) { ... } //为什么不是for(auto p : m)？
2.所谓的可不见的内部代理类：auto highPriority = static_cast<bool>(features(w)[5]);

---

3. Moving to Modern C++

1. 区别()与{}（初始化对象）
    1. 如果类定义了std::initializer_list构造函数的话，{}优先匹配（不管实际的参数类型）//C++编译器的灵活性有点缺乏
        1. 用空std::initializer_list初始化：Widget w4({}); //直接Widget w4{};调用默认构造
    2. 变参模板（这让我想起了Scheme syntax-rules变态的模式匹配语法）
        1. template<typename T, typename... Ts>
        2. void doSomeWork(Ts&&... params){
            1. T localObject(std::forward<Ts>(params)...);
2. Prefer nullptr to 0 and NULL（这样的条款有点侨情）
    1. f(nullptr); // calls f(void*) overload
3. Prefer alias declarations to typedef's
    1. 别名声明：using UPtrMapSS = std::unique_ptr<std::unordered_map<std::string, std::string>>;
        using FP = void (*)(int, const std::string&);
        template<typename T> using MyAllocList = std::list<T, MyAlloc<T>>;
            老实的写法：需要typename告诉编译器内部名字是一个类型不是变量，没有using好？
    基于<type_traits>的类型特性擦除：
        std::remove_const<T>::type
        std::remove_reference<T>::type
4. Prefer scoped enums to unscoped enums
    enum class Color { black, white, red }; //但这样一来，引用枚举量时都需要那个枚举类名前缀
    enum class Status: std::uint32_t;
5. =delete
6. overriding发生的前提：***
    基类需要声明virtual
    函数名必须相同（废话）
    参数类型必须相同（*）
    const性质必须相同（*）
    返回类型和异常规格必须兼容（*）
    C++11：引用限定必须相同：void f() &; void f() &&;（代表f只能在左值/右值对象上调用）
7. override是上下文关键字（C++11特性），可用作函数名称
8. Prefer const_iterators to iterators
    作者又在强调常量迭代器了，但实际上，STL的非常量迭代器通常更有效
    定义非成员版本的cbegin：//优先非成员只不过是作者偏好FP风格的体现
        template <class C> auto cbegin(const C& container)->decltype(std::begin(container)) { ... }
            注意，const类型修饰只是为了让编译器帮助我们完成一些编译器的类型安全检查
9. noexcept
    vs C++98 throw() //差别在发生异常时的stack unwinding处理上，略
    有条件的noexcept：noexcept(noexcept(swap(*a, *b)))
10. constexpr
    代表const in const out，可用作编译期的常量
    C++11里对函数的一些限制：略（这只不过是编译器的实现问题，C++有时候老是会把语言、库与编译器实现混淆在一起！）
    *C++14：setter也可以是constexpr
11. const成员函数应该是线程安全的
    可以修改mutable数据成员
    如果要一次修改多个atomic，使用mutex保护一致性：std::lock_guard<std::mutex> g(m);
12. 理解特殊的成员函数生成
    copy操作（构造&赋值）、move操作
    C++11里，如果用户定义了dtor（析构函数），则move操作不会自动生成 => 可使用=default绕过
    Member function templates never suppress generation of special member functions（C++里的偏僻规则太多了）
        有些规则只对库设计者才有意义，使用者（App开发者）只需遵循编码规范就可以了

---

4. Smart Pointers

1. C++11: std::auto_ptr, std::unique_ptr, std::shared_ptr, and std::weak_ptr
2. std::unique_ptr
    1.定制deleter：
        auto delA = [](A* a){ ... delete a;}
        std::unique_ptr<A, decltype(delA)> makeA(...){ ... }
    转换为std::shared_ptr
3. std::shared_ptr
    1. 通常，保存引用计数的'控制块是动态分配的
        但std::make_shared将控制块与对象内存绑定到一起，这给对象的真正释放内存带来了麻烦
        对比：std::shared_ptr<Widget> spw1(pw, loggingDel); //创建一个新的控制块
    2. 奇特递归模板：class Widget: public std::enable_shared_from_this<Widget> { ... }
        shared_from_this()之前需要已有std::shared_ptr引用
            ==> private ctor，+定义static create方法
4. std::weak_ptr
    1. 弱引用指针通常与引用计数指针配合使用：std::weak_ptr<Widget> wpw(spw);
        1. if (wpw.expired()) ...
        2. auto spw2 = wpw.lock();
    2. 实现细节：std::shared_ptr的控制块中存储了弱引用计数？
5. std::make_unique和std::make_shared
    1. 资源泄漏：processWidget(std::shared_ptr<Widget>(new Widget), computePriority());
        1.==> processWidget(std::make_shared<Widget>(), computePriority());
6. 当使用Pimpl习俗时，需要定义特殊的成员函数（dtor及move操作）
    定制deleter是std::unique_ptr类型的一部分，但不是std::shared_ptr类型的一部分

---

5. Rvalue References, Move Semantics, and Perfect Forwarding

1. 即使声明为void f(T&& a); 参数总是左值
2. 理解std::move和std::forward
    1. std::move和std::forward既不移动也不转发，只是类型转换（运行时什么也不做）
    2. std::move无条件把参数转换为右值，而std::forward要求实参必须是右值（注意，形参总是左值）
        1. move构造函数的参数是非const的，但copy构造函数的参数是const的，这一差别允许const右值实参调用copy构造
    1. std::move总是可以换成std::forward
3. 区别‘通用引用’和右值引用
    1. 不是右值引用：
        1. void f(T&& param);
        2. auto&& var2 = var1; //前提：存在类型推导
    2. 右值引用：
        1. void f(Widget&& param);
        2. Widget&& var1 = Widget();
        3. void f(std::vector<T>&& param);
        4. void f(const T&& param);
        5. 即使写成T&&但不存在类型推导的情况（从类模板实例化得到的成员函数 vs 成员函数模板）
    3. C++14：
        1. [](auto&& func, auto&&... params){ std::forward<decltype(func)>(func)(std::forward<decltype(params)>(params)...); }
4. 在右值引用上使用std::move，在通用引用上使用std::forward
    1. return std::move(lhs); //不发生“copy到临时对象”，注意lhs是‘通用引用’（T&&类型参数）
    2. 不要return std::move局部对象（这种情况下反而无法RVO）
        1. 编译器能够做RVO，即使你不写成return Widget();？
            1. 这里面有点扯淡，因为仅仅是“C++标准委员会”这么说的，作者似乎混淆了TMP（模板元编程）和普通的写法
5. Avoid overloading on universal references
    1. copy构造函数的参数总是const的，一个非const的参数将优先匹配universal reference构造函数模板
6. tag dispatch？脑抽！
7. std::enable_if
    1. typename = typename std::enable_if<condition>::type //靠，真是疯狂
    2. typename std::decay<T>::type：去除类型T的引用、const、volatile修饰
        1. condition：!std::is_same<Person, typename std::decay<T>::type>::value
        2. C++14语法：std::decay_t<T>（不必再写typename）
8. std::is_base_of<T1, T2>::value
9. 理解引用塌陷
        1. 不允许用户声明引用的引用，但是编译器可以这么做？只要有一个是lvalue引用，结果就是左值引用
        2. 4个上下文：模板实例化、auto类型推导、typedef和using类型别名、decltype
10. 完美转发
    1. template<typename T> void fwd(T&& param){ f(std::forward<T>(param)); }
    2. template<typename... Ts> void fwd(T&&... param){ f(std::forward<T>(param)...); }
    3. 失败的情况：（无法类型推导，或不正确的推导）
        1. braced initializer：void f(const std::vector<int>& v); ==> fwd({ 1, 2, 3 });
        2. 0 or NULL as null pointers
        3. 重载的函数指针、模板函数 ==> 手工地指定函数重载或实例化版本
        4. struct中的bit域（无法以非const寻址）
    4. p211 references are simply pointers that are automatically dereferenced

---

6. Lambda Expressions

1. 避免默认捕获
    1. using FilterContainer = std::vector<std::function<bool(int)>>;
    2. filters.emplace_back( [](int value) { return value % 5 == 0; } );
    3. [&] 与 [=]
    4. 不能捕获成员变量，捕获的是this指针（隐式）
        1. 全局变量和static局部变量是引用不是捕获，捕获真针对局部变量（？）
2. Use C++14 init capture to move objects into closures
    1. auto pw = std::make_unique<Widget>();
    2. auto func = [pw = std::move(pw)] { ... }
        1. => auto func = [pw = std::make_unique<Widget>()] { ... }
    3. move capture的C++11仿真：
        1. auto func = std::bind( [](const std::vector<double>& data){...}, std::move(data) );
        2. Chromium代码里有类似的写法：void InProcessCommandBuffer::Destroy() {
            1. base::WaitableEvent completion(true, false);
            2. bool result = false;
            3. base::Callback<bool(void)> destroy_task = base::Bind( &InProcessCommandBuffer::DestroyOnGpuThread, base::Unretained(this));
            4. QueueTask(base::Bind(&RunTaskWithResult<bool>, destroy_task, &result, &completion));
        3. mutable lambda？（见鬼，之前怎么没见过这种语法）
3. Use decltype on auto&& parameters to std::forward them
    1. C++14 泛型lambda？：auto f = [](auto x){ return func(normalize(x)); };
    2. 完美转发：
        1. auto f = [](auto&& param){ return func(normalize(std::forward<decltype(param)>(param))); };
        2. variadic的版本：略
4. Prefer lambdas to std::bind
    1. bind对象（实际上是一个函数对象，注意，lambda也是！）
    2. lambda更可读（这倒是真的，bind有点像FP里的currying）
    3. p233 C++14 using namespace std::literals; //特殊的类型常量后缀语法，如1h 30s
    4. bind传参now()的话，传的是bind时的时间，而不是目标函数被调用时的时间（嗯，这让我想起了JavaScript里类似的问题）
        1. 推迟求值：auto setSoundB = std::bind(setAlarm,
            1. std::bind(std::plus<>(), steady_clock::now(), 1h), _1, 30s);
    5. 注意这里的语法，bind嵌套了bind以惰性求值
    6. std::bind总是复制参数，但可以用std::ref来传引用：
        1. auto compressRateB = std::bind(compress, std::ref(w), _1);
    7. std::bind可接受任意类型，假设PolyWidget::operator()是成员模板，则可：auto boundPW = std::bind(pw, _1);
        1. C++11 lambda：无等价形式
        2. C++14：auto boundPW = [pw](const auto& param){ pw(param); }; //但这种多态lambda有实际用途吗

---

7. The Concurrency API

1. Prefer task-based programming to thread-based
    1. auto futureResult = std::async(doAsyncWork);
    2. 线程：硬件（CPU）、软件（OS）、std::thread对象
        1. 即使函数不抛异常：int doAsyncWork() noexcept;，std::thread t(doAsyncWork);也有可能因为资源不足抛错
        2. oversubscription问题（增加了调度开销）
    3. std::async有可能在当前线程里执行doAsyncWork（异步的形式，实质却是同步函数调用），避免了线程过载
    4. GUI线程响应问题：显示指定std::launch::async启动策略
        1. 话说这里的讨论似乎与Chromium impl-side painting的目标有相通之处。。。
2. Specify std::launch::async if asynchronicity is essential
    1. 启动策略：std::launch::async 或 std::launch::deferred（直到在future上get/wait，此时同步执行）
    2. if (fut.wait_for(0s) == std::future_status::deferred){ //那么直接同步调用？
    3. 作者怎么这么喜欢写wrapper函数？std::result_of<F(Ts...)> ...
3. Make std::threads unjoinable on all paths
    1. implicit join：线程对象的析构函数会等待线程的执行完成（C++的这个API设计其实是有问题的，应该像Java那样提供显式的start方法）
    2. ~ThreadRAII()：if (t.joinable()) { t.join() or detach() }
4. Be aware of varying thread handle destructor behavior
    1. 线程执行结果：不能存在callee的std::promise，也不能是caller的std::future（可转换为shared_future）
        1. ==> shared state（实际上存放在堆里）
    2. The normal behavior is that a future’s destructor destroys the future object. That’s it.
    3. ？
    4. std::packaged_task（略）
    5. The final future referring to a shared state for a non-deferred task launched via std::async blocks until the task completes
        1. 这话说得太拗口了，其实不就是在析构函数里阻塞等待嘛
5. Consider void futures for one-shot event communication
    1. std::condition_variable cv; //条件变量上wait有可能导致CPU繁忙吗？
    2. std::mutex m; //条件变量需要互斥访问，用mutex来保护
    3. 通知方：cv.notify_one();
    4. 等待方：{std::unique_lock<std::mutex> lk(m); cv.wait(lk); ...}
    5. 问题：
        1. mutex是否必需？
        2. wait之前notify将导致hang
        3. spurious wakeups：wait不是由于notify（这种情况下需要把wait放到while循环里？）
    6. 由于只通知一次，考虑使用一个开关状态变量：std::atomic<bool> flag(false);
        1. while (!flag); //但是这样会导致忙等
    7. 使用普通bool flag; 但是用mutex加锁：
        1. {std::lock_guard<std::mutex> g(m); flag = true;} cv.notify_one();
        2. {std::unique_lock<std::mutex> lk(m); cv.wait(lk, [] { return flag; }); ...} //避免了notify信号丢失的问题
    8. caller-callee一次通信：使用future-promise
        1. std::promise<void> p;
        2. 通知方：p.set_value();
        3. 等待方：p.get_future().wait(); //没有mutex？那就是说没有加锁，那么底层是怎么做到的？
        4. 注意，promise和future之间是一个动态堆分配的shared_state
    9. p269 如果发生了异常的情况？（C++这种命令式语言要在异常情况下仍然能够保证事务处理的一致性恐怕有点困难）
    10. auto sf = p.get_future().share(); ...（下略）
6. Use std::atomic for concurrency, volatile for special memory
    1. volatile：不能保证读与写操作的原子性，并且‘数据竞争’可导致无法预测/未定义的行为（编译器可生成任意指令？）
    2. std::atomic限制了指令重排：写操作完成之前，不允许后续指令提前执行（感觉这更像是Java里的volatile？）
    3. volatile std::atomic<int> vai;

---

8. Tweaks

1. Consider pass by value for copyable parameters that are cheap to move and always copied
    1. 重载 const std::string& 和 std::string&&
    2. T&& 加 std::forward<T>
    3. std::string传值 加 std::move
    4. C++98：经典的slicing问题（指的是一个子类对象传值给一个基类形参）
2. Item 42: Consider emplacement instead of insertion
    1. 42，不错的数字~
    2. 直接传递一个字符串常量给一个std::string&参数？临时对象析构和std::move开销
        1. vs.emplace_back("xyzzy"); //使用完美转发，直接在vector<string>容器内部构造一个string对象
    3. 嗯，把它称为‘就地插入’
    4. heuristics：
        1. The value being added is constructed into the container, not assigned
        2. The argument type(s) being passed differ from the type held by the container
        3. The container is unlikely to reject the new value as a duplicate
    5. 对shared_ptr不适用vp.emplace_back( new Widget())？
        1. 但是如果先构造td::shared_ptr<Widget> spw(new Widget, killWidget);的话，则push_back、emplace_back无差别
    6. 与explicit构造函数的交互
        1. 可以regexes.emplace_back(nullptr);，那是因为regex允许从nullptr explicit构造
            1. std::regex r(nullptr); 可以通过编译，但是属‘未定义行为’
            2. 注意，前者是直接初始化，而std::regex r=nullptr;写法是拷贝初始化