#C++

当 int/long/float/指针/std::string 作为 std::unordered_map 的 key 时，C++底层是如何计算 hash 值的？

gcc/clang 作为使用最多的两种编译器和标准库，它们在这个问题的实现上略有差异。本文将基于二者的源码进行对比分析。

C++17 中引入了 std::any，可以非常方便地将任意类型的变量放到其中，做到安全的类型擦除。然而万物皆有代价，这种灵活性背后必然伴随着性能取舍。

std::any 的实现本身也并不复杂，本文将基于 libstd++ 标准库源码 深入解析其实现机制与性能开销。

我们在使用 C++ 的时候，有时会需要在类的内部获取自身的 shared_ptr，这就会用到 std::enable_shared_from_this。在实际使用过程中，std::enable_shared_from_this 有三个陷阱需要注意：

libco 是微信后台开发和使用的协程库，同时也是极少数的直接将 C/C++ 协程运用到如此大规模的生产环境中的案例。

在 《云风 coroutine 协程库源码分析》 中，介绍了有栈协程的实现原理。相比云风的 coroutine，libco 在性能上号称可以调度千万级协程。 从使用上来说，libco 不仅提供了一套类 pthread 的协程通信机制，同时可以零改造地将三方库的阻塞 IO 调用进行协程化。

本文将从源码角度着重分析 libco 的高效之道。

在正式阅读本文之前，如果对有栈协程的实现原理不是特别了解，建议提前阅读 《云风 coroutine 协程库源码分析》。

同时，我也提供了 libco 注释版，用以辅助理解 libco 的源码

C++11 中推出了三种智能指针，unique_ptr、shared_ptr 和 weak_ptr，同时也将 auto_ptr 置为废弃 (deprecated)。

最近在写 C++ 时，有这样一个代码需求：在 lambda 中，将一个捕获参数 move 给另外一个变量。 看似一个很简单常规的操作，然而这个 move 动作却没有生效。

具体代码如下：

std::vector<int> vec = {1,2,3};

auto func = [=](){
    auto vec2 = std::move(vec);
    std::cout << vec.size() << std::endl; // 输出：3
    std::cout << vec2.size() << std::endl; // 输出：3
};

代码可在 wandbox 运行。

我们期望的是，将对变量 vec 调用 std::move 后，数据将会移动至变量 vec2, 此时 vec 里面应该没有数据了。但是通过打印 vec.size() 发现 vec 中的数据并没有按预期移走。

这也就意味着，构造 vec2 时并没有按预期调用移动构造函数，而是调用了拷贝构造函数。

为什么会造成这个问题呢, 我们需要结合 std::move 和 lambda 的原理看下。（最终的解决方案可以直接看 这里）

muduo是 陈硕 大神个人开发的 C++ 的 TCP 网络编程库。muduo 基于 Reactor 模式实现，Reactor 模式也是目前大多数 Linux 端高性能网络编程框架和网络应用所选择的主要架构，例如 Redis 和 Java 的 Netty 库等。

陈硕的《Linux 多线程服务器端编程》一书对 muduo 整个架构进行了非常详尽的介绍和分析，可以说是学习 muduo 源码和设计理念最好的资料了。

而本文则主要是从源码角度辅助理解整个 muduo 的实现，同时也姑且算是对 muduo 的一个小小的补充。

同时我也提供了一个 muduo 注释版，用以辅助理解 muduo 的源码。