C++ on Anfsity

You Dont Know Cpp and Neither I Do

Mon, 27 Apr 2026 16:24:07 +0800

来点语言律师题，之前刷 reddit 看到的，作者取了个非常中二的名字（，空闲时间做了把他搬过来了。

原文仓库: https://github.com/0xd34df00d/you-dont-know-cpp

Assigning to references

Does this work? If it doesn’t, why and what’s the easiest fix?

constexpr decltype(auto) Get()
{
  static int longLiving = 0;
  auto& ref = longLiving;
  return ref;
}

void DoFoo()
{
  Get() = 42;
}

What about this one? If this one doesn’t, why and what’s the easiest fix?

struct Foo { int a; };

template<int Idx, typename T>
constexpr decltype(auto) Get(T& f)
{
  auto& [...fields] = f;  // C++26 structured binding introducing a pack
  return fields... [Idx];
}

void DoFoo()
{
  Foo f;
  Get<0>(f) = 42;
}

第一个是对的，第二个是错的，为什么呢？

根据 decltype 的规定，我们可以推导出：

写法	`decltype` 推导结果	语法分类	推导出的返回类型	结果
`return fields...[Idx];`	规则 1：`decltype(entity)`	id-expression	`int` (传值)	产生 prvalue，报错
`return (fields...[Idx]);`	规则 2：`decltype(expression)`	lvalue	`int&` (传引用)	产生 lvalue，合法

在不带括号时 fields...[Idx] 是一个 id-expression。其被推导为 decltype(entity) 里的 entity。对于结构化绑定，编译器会直接提取它底层绑定的变量类型。在这里，底层类型是 int。因此，decltype(auto) 将函数返回值推导为 int。函数返回一个 prvalue，你不能对一个 pvalue 赋值。

而我们加上括号后，括号强制改变了它的语法属性，使其变成了一个左值表达式，此时编译器触发 decltype(expression) 规则。因为该表达式是一个 lvalue，标准规定 decltype 必须将其推导为引用类型 int&。因此，函数返回了对原始数据的引用，赋值操作完全合法。

我找到一篇写的很详细的博客 C++ value categories and decltype demystified: https://www.scs.stanford.edu/ ~dm/blog/decltype.html

Defaulted equality

Does this work?

#include <compare>

// note no operator==
struct Foo
{
    int a;
    std::strong_ordering operator<=>(const Foo&) const = default;
};

bool testFoo(Foo f1, Foo f2)
{
    return f1 == f2;
}

Does this work?

struct Bar
{
    int a;
    std::strong_ordering operator<=>(const Bar&) const;
};

std::strong_ordering Bar::operator<=>(const Bar&) const = default;

bool testBar(Bar b1, Bar b2)
{
    return b1 == b2;
}

<=> 是 cpp 20 引进的一个新特性，他的核心是，比较时不返回 bool，而是返回一个序关系。这是一个很方便的特性，使用它，在重载运算符上就变得十分方便。是我十分喜欢的一个抽象。

这是一个例子：https://godbolt.org/z/34EjovMca

在这一节的 3.2 中，说明：

If the member-specification does not explicitly declare any member or friend named operator==, an == operator function is declared implicitly for each three-way comparison operator function defined as defaulted in the member-specification , with the same access and function-definition and in the same class scope as the respective three-way comparison operator function, except that the return type is replaced with bool and the declarator-id is replaced with operator== 机翻：如果成员声明没有显式声明任何名为 operator== 的成员或朋友，则对于在成员声明中定义为默认的三向比较运算符函数，会隐式声明一个 == 运算符函数，具有相同的访问权限和函数定义，并在相应的三向比较运算符函数的相同类作用域中，但返回类型被替换为 bool，声明标识符被替换为 operator==

在第一个例子中，<=> 被声明为了 default，同时 == 也会被声明。但是在第二个例子中，由于我们没有给出 <=> 的默认实现，编译器不会为我们声明 == 函数，就算我们在后面补充上了 <=> 的实现，== 依旧依赖于我们手动实现。

Specialization fun

You have this in your header:

template<typename>
constexpr auto IsSimpleContainer = [] { struct Undefined {}; return Undefined {}; } ();

template<typename T>
constexpr bool IsSimpleContainer<std::vector<T>> = true;

// vectors of bools are very special!
template<>
constexpr bool IsSimpleContainer<std::vector<bool>> = false;

template<typename T>
constexpr bool IsSimpleContainer<std::deque<T>> = true;

How can this bite you?

It’s alright if only one TU includes this header. But if more than one does, the linker might complain on a CWG 2387-conforming implementation: a fully specialized variable template (the one for std::vector<bool>) is a variable definition, so all the usual variable linkage rules apply.

The fix is to add inline to that line only:

1
2

template<>
inline constexpr bool IsSimpleContainer<std::vector<bool>> = false;

Also, constexpr doesn’t help: unlike constexpr functions, constexpr variables are not implicitly inline.

Bonus points for …

… immediately thinking “unless they are static class data members, of course!” when reading the previous sentence.

`requires`-constrained return types

template<typename... Args>
struct Dummy
{
  int value;

  void foo()
    requires(sizeof... (Args) == 0)
  {
  }

  std::optional<Args...> foo()
    requires(sizeof... (Args) == 1)
  {
    return {};
  }

  std::optional<std::tuple<Args...>> foo()
    requires(sizeof... (Args) > 1)
  {
    return {};
  }
};

int main()
{
  Dummy<> d { 42 };
}

Dummy<> does not typecheck. Do you expect it to not typecheck? Why it does not typecheck and how to fix it?

Solution constraint

No, you are not allowed to hide it under auto + deduced type. For the actual type in the actual use case that prompted writing this, the return type then needs to be written in every branch, and it’s annoying, and also reduces discoverability of the API.

看似可以完美的触发 SFINAE，但是不妨注意到，在 std::optional<Args...> foo 中，如果 Args...为空，这里就是一个 hard error，正如编译器给出的 Too few template arguments for class template 'optional'。

如何修复呢？

我们可以用一个基类 DummyBase 来包装，再根据包的大小特化 Dummy ，如 https://godbolt.org/z/vdPsojqv3

我们也可以用一个辅助类型来包装，确保 optional 里面永远不为空，就像这样：

template<typename... Ts>
struct OptionalReturn {
    using type = void;
};

template<typename T>
struct OptionalReturn<T> {
    using type = std::optional<T>;
};

template<typename... Ts> requires (sizeof...(Ts) > 1)
struct OptionalReturn<Ts...> {
    using type = std::optional<std::tuple<Ts...>>;
};

template<typename... Args>
struct Dummy {
    int value;
    // 此时即使 Args 为空，OptionalReturn<Args...>::type 也只是一个类型定义
    // 不会触发 std::optional 的错误展开
    typename OptionalReturn<Args...>::type foo(); 
};

Bonus question

Some usual approaches don’t work:

Making foo itself a template with a default template parameter, like
1 2 3

template<typename... MyArgs = Args...> requires(sizeof...(MyArgs) == 1) std::optional<MyArgs...> foo()
is not well-formed since packs can’t have default values.
Using something like template<typename T = std::tuple_element_t<0, std::tuple<Args...>> and then having std::optional<T> in the “unary” foo() case: std::tuple_element_t hard-errors on out-of-bounds index instead of merely being SFINAEd away.
A C++26 variation of that with pack indexing with template<typename T = Args...[0]>: out-of-bounds in pack indexing is also somehow a hard error instead of being SFINAEd away.

Given this, what can you say about orthogonality and well-thought-ness of C++?

hhh, 我不好说。

Is this valid?

struct Foo
{
  struct Nested
  {
    bool field = true;
  };

  void doSmth(const Nested& = Nested{});
};

Answer: see this bugzilla entry .

为了让我们在类成员函数中使用后面才会定义的变量，编译器不会立即处理两种内容，直到整个类结束后才会构造，这里第一是类成员变量的初始值，第二是函数的默认构造函数。

在这个代码中，由于 doSmth 还在类中，我们 Nested 不存在构造函数，一旦我们写下 const Nested& = Nested{}，就代表我们需要 Nested 有构造函数。这是什么，循环依赖了，万测尽，悲。

理解了原理，似乎我们也很好修改，只需要给 Nested 手动添加一个构造函数就行了。但是，如下代码依然会有错误：

struct Foo
{
  struct Nested
  {
    bool field = true;
    Nested() = default;
  };

  void doSmth(const Nested& = Nested{});
};

因为将构造函数声明为 default 和直接表明我们这个 Nested 类有构造函数 Nested() {}; 是不一样的，default 不代表 Nested 类一定有构造函数，这取决于类的实现。

值得一提的是，msvc，会编译成功，哈哈哈哈。

Some covariance (协变)

Is this valid?

struct Base
{
  virtual Base* getFoo() { return nullptr; }
};

struct Derived : Base
{
  Derived* getFoo() override { return nullptr; }
};

Sure: this is covariance in action.

What about this?

struct Base
{
  virtual const Base* getFoo() { return nullptr; }
};

struct Derived : Base
{
  Base* getFoo() override { return nullptr; }
};

Yep, also good: in some sense, Base* is a subtype of const Base*. And, of course, Derived* would’ve worked too.

Now, this is surely valid too, right?

struct Base
{
  virtual const int* getFoo() { return 0; }
};

struct Derived : Base
{
  int* getFoo() override { return 0; }
};

Nope: non-class types play by different rules, because otherwise the language would’ve been too consistent (see https://eel.is/c++draft/class.virtual #8).

那么问题来了，我们要怎么正确是实现呢？

一个显然的思路是包装一下我们的 int，但这样不够通用而且太繁琐了。

额，如果忽视 runtime 环境的话，用 CRTP 可以很好的解决这个问题：

template <typename Derived, typename T> struct Base {
    T *getFoo() { return static_cast<Derived *>(this)->getFooImpl(); }
};

struct Derived : Base<Derived, int> {
    int *getFooImpl() { return &data; }
    int data;
};

还有别的方法吗？我们也可以这么处理：

struct Base {
    virtual const int *getFoo() const { return getFooImpl(); }

  protected:
    virtual const int *getFooImpl() const { return nullptr; }
};

struct Derived : Base {
    using Base::getFoo;
    int *getFoo() { return const_cast<int *>(getFooImpl()); }

  protected:
    const int *getFooImpl() const override {
        return nullptr;
    }
};

这么写显然很丑陋。。

`constexpr` string literals

Does this compile?

constexpr auto f() { return "f"; }
constexpr auto g() { return "g"; }

static_assert(f() == f());
static_assert(f() != g());

Here the answer is easy: it’s an open question, discussed in CWG #2765 .

可能会有 Static assertion expression is not an integral constant expression ，因为在比较字符串地址。

如果要比较，请不要使用 auto。

When is this function safe or unsafe to use?

1
2

template<auto V>
const auto& foo() { return V; }

u1s1, 有点幻视：

1
2

auto<auto auto>
auto auto& auto() { auto auto; }

It’s safe for class types and unsafe for, say, ints. For some reason the standard threats them differently, so

const auto& v1 = foo<42>();       // bad! dangling reference

struct S { int val; };
const auto& v2 = foo<S { 42 }>(); // fine!

Finding the corresponding clauses in the standard is left as an exercise for the reader.

Maps of non-copyable, non-movable types

Suppose you have a type that’s not copyable nor movable, like

struct ThreadedResource
{
  std::unique_ptr<Resource> handle;
  std::mutex mutex; // mutex isn't move-constructible nor move-assignable nor copyable
};

假设你需要一个把从 int 映射到 ThreadedResource 的 hashmap。一个方法是使用 shared_ptr 来包装一下 ThreadedResouce。如 std::unoredred_map<int, std::shared_ptr<ThreadedResource>>。空指针表示这里没有映射。

这很麻烦（？）因为它会有额外的内存开销和访问，导致了性能下降。

你能做的更好吗？

一个可能的答案是使用 std::optional,它可以更清晰的表达 “no value”。

因为对象不能移动，我们得使用分段构造 piecewise_construct：

auto handle = ...;
map.emplace(std::piecewise_construct,      // 将 key 和 value 分开构造
// forward as tuple：将构造函数需呀哦的参数打包成元组
            std::forward_as_tuple(locale), // key
            std::forward_as_tuple(
            std::in_place,             // 就地构造
            std::move(handle))

请注意，ThreadedResource 字段的顺序是 mutex 在 handle 之后，

因此无需向 mutex 传递初始化器，一切都能正常运行。

Incrementing enums

Is this valid?

enum E { A, B };

E& operator++(E& e)
{
    // some implementation
}

虽然我们不能对枚举自增，但是我们可以重载枚举的 ++ 运算符。

比如：

#include <iostream>
#include <cassert>

enum Status {
    ready,    // 0
    running,  // 1
    stopped   // 2
};

// 重载前置 ++
Status& operator++(Status& s) {
    if (s == stopped) {
        s = ready;
    } else {
        s = static_cast<Status>(static_cast<int>(s) + 1);
    }
    return s;
}

int main() {
    Status myStatus = ready;
    ++myStatus; // 现在 myStatus 变成了 running
	assert(myStatus == running);
    return 0;
}

`operator new`

Is this valid?

struct Bar
{
    int n;

    void* operator new(size_t sz)
    {
        return ::operator new(sz + n);
    }
};

How about this?

struct Bar
{
    virtual void* operator new(size_t sz)
    {
        return ::operator new(sz);
    }
};

显然不对，new 操作符是隐式 static 的，而此时 n 还没有创建完成。既然对象不存在，哪里来的分配内存？对于虚函数来说，此时同理没有 vtbl。

How are these two functions different?

template<typename T>
T mkT1() { return {}; }
   
template<typename T>
T mkT2() { return T {}; }

mkT1 是复制列表初始化，mkT2 是直接列表初始化。

他们直接的区别在于对 explicit 构造函数的处理。T1 函数不允许调用标记为 explicit 的构造函数。

并且在 c++ 17 之前，T{} 会创建一个临时对象，这导致 std::mutex 这种无法使用。

Is this code valid?

struct Foo
{
  int a;

  Foo() = delete;
  Foo(int) = delete;
};
   
int main()
{
  Foo foo1 {};
  Foo foo2 { 10 };
}

这同样涉及到 cpp 的初始化，在 c++20 之前，一个类被视为聚合体，如果：

没有用户提供的构造函数
没有私有或保护的非静态数据成员
没有基类，没有虚函数

在这里，Foo() = delete 属于用户声明，但不属于用户提供。所以他被视为聚合体。在聚合初始化中，编译器会绕过构造函数，直接给成员赋值而不需要构造函数。

这就导致了上面这种看起来很不合理的代码在 c++17 标准下可以编译通过。

btw， c++20 修改了聚合体的定义，以上代码无法在 c++20 以上编译。

(^=…=^)

What does this code do, and on what features of C++17 does it rely?

template<typename F, typename... Ts>
void foo(F f, Ts... ts)
{
  int _;
  (_ = ... = (f(ts), 0));
}

这个标题幻视我们的反射 [:O_o:]

这个代码很难读，实际上 cpp 模板里面有很多这样很难读的代码。。。。。。

它依赖了变长参数模板，折叠表达式，赋值运算符的评估顺序。简单的来说，如果我们调用 foo(func, 1, 2, 3) 其会依次调用 func(3) func(2) func(1)。

我们详细讲解一下。

假设我们调用 foo(f, t1, t2) ，(_ = ... = (f(ts), 0)) 是一个二元左折叠。其结构 (Init op ... op Pack)。

展开后，看起来像这样： ((_ = (f(t1), 0)) = (f(t2), 0))。根据 c++17 标准，在表达式 A = B 中，B 在 A 先执行。所以先执行 t2 然后再 t1。

这个代码有什么问题呢？当我们偷偷重载了 operator, 或 operator= 的时候，就有可能有问题。

当然，还有一个最大的问题，就是可读性太差太差了。。。

Conceptual concepts

Assume the following declarations:

template <typename T>
concept Trivial = std::is_trivial_v<T>;

template <typename T, typename U>
  requires Trivial<T>
void f(T t, U u) { std::cout << 1; }

template <typename T, typename U>
  requires Trivial<T> && Trivial<U>
void f(T t, U u) { std::cout << 2; }

Is f(1, 2) valid? If yes, what would it print?
What if Trivial<T> && Trivial<U> is replaced by Trivial<T> && Trivial<T> in the second definition?
What about Trivial<T> || Trivial<U>?
What if the definition of Trivial gets “inlined”, replacing all Trivial<T>s with sd::is_trivial_v<T>?

答案是 2,

Call to 'f' is ambiguousclang(ovl_ambiguous_call)

foo.cpp(10, 6): Candidate function [with T = int, U = int]

foo.cpp(16, 6): Candidate function [with T = int, U = int]

1 和 ambiguous。

Fun with fun templates

What does bar1 print?

template<typename T>
int foo(T) { return 1; }

template<>
int foo(int*) { return 2; }

template<typename T>
int foo(T*) { return 3; }

void bar1()
{
    int test;
    std::cout << foo(&test) << foo<int>(&test) << foo<int*>(&test) << '\n';
}

What if we reorder the definitions, as in bar2?

template<typename T>
int foo(T) { return 1; }

template<typename T>
int foo(T*) { return 3; }

template<>
int foo(int*) { return 2; }

void bar2()
{
    int test;
    std::cout << foo(&test) << foo<int>(&test) << foo<int*>(&test) << '\n';
}

Can we still specialize the first template after we’ve introduced the second one?

Yep:

1
2

template<>
int foo<int*>(int*) { return 2; }

把这个和上面那个放在一起来讲吧。当初学模板元做的笔记：

在类模板的特化过程中，编译器会先将模板转化成函数模板，借助函数模板重载来决定优先级。

函数模板偏序规则：

如果模板 A 能够处理的所有情况，模板 B 都能处理。而模板 B 能处理的情况，模板 A 未必能处理。则模板 A 比 B 更特化。

文章的意思大概是：编译器捏造一个类型 U，用类型 U 带入模板 A，生成一个具体的函数签名。然后用这个函数签名，去试图匹配模板 B 如果能匹配，则说明 A 比 B 特化。反过来做一遍，就能够比较 A 和 B 的特化程度了。

1
2

template <typename T> void foo(T);   // #1
template <typename T> void foo(T *); // #2

如果我们要比较 #1 和 #2 的特化程度，首先，尝试 #2 带入 #1 ，我们用一个模板实参 U（比如说 int）带入 #2。也就是 template <typename T = U> void foo(U *); （foo(int *)）然后尝试 U* 带入 #1，也就是 template <typename T> void foo(U *)（可以想象成 foo(int *) 去匹配 #1）此时，#1 的 T 可以被推导为 U*。

然后，我们再尝试用 #1 带入 #2，同理用一个模板实参 U 带入 #1 template <typename T = U> void foo(U); 去匹配 #2，得到 T* = U -> 失败

综上得出：#2 的特化程度比 #1 高。

函数模版既可以重载，又可以全特化，函数模板的每一个重载都是主模板。实例化过程中，先进行重载决议，然后再特化匹配。也就是说，在重载决议阶段，只考虑主模板，不考虑主模板的全特化。选择主模板后，才进行特化匹配。这样的规则会导致：如果模板特化的位置不同，最终匹配到的模板也有可能不同。所以我们不应该使用函数模板全特化，而是使用函数重载。

放在这里就是：

下面的解析是 AIGC。

1
2
3

template<typename T> int foo(T) { return 1; }   // #1 (主模板)
template<> int foo(int*) { return 2; }          // #1 的特化 (因为此时只有 #1 可见)
template<typename T> int foo(T*) { return 3; }  // #2 (另一个主模板)

foo(&test)：
- 主模板 #1 (T=int*) 和 #2 (T=int) 都在候选名单中。
- 根据偏序规则，#2 比 #1 更特化（$T*$ 优于 $T$）。
- 选择 #2。由于 #2 在此处没有特化版本，返回 3。
foo<int>(&test)：
- 指定 T=int。只有 #2 匹配（foo(int*)）。返回 3。
foo<int*>(&test)：
- 指定 T=int*。
- #1 变为 foo(int*)，匹配。
- #2 变为 foo(int**)，不匹配。
- 选择 #1。检查 #1 的特化，发现 foo(int*)，返回 2。

结果：332

1
2
3

template<typename T> int foo(T) { return 1; }   // #1
template<typename T> int foo(T*) { return 3; }  // #2
template<> int foo(int*) { return 2; }          // #2 的特化 (因为 #2 比 #1 更特化)

注意：这里的全特化 template<> int foo(int*) 会关联到当前最匹配的主模板，即 #2。

foo(&test)：
- 选择主模板 #2。检查其特化，发现 foo(int*)。返回 2。
foo<int>(&test)：
- 选择主模板 #2。检查其特化，发现 foo(int*)。返回 2。
foo<int*>(&test)：
- #1 匹配，#2 不匹配。
- 选择 #1。#1 在此处没有特化。返回 1。

结果：221

I C `memset`

Assume an instance of a struct is memseted to zeroes. What would be the value of the padding?

Further assume a field of that structure is updated. What would be the value of the padding after that field? After other fields?

都是未指定的。

为了更加直观的了解这个，我们来看看其内存模型。

假设有这么一个类：

struct Sample {
  char a;    // 1 byte
  // Padding: 3 bytes
  int b;     // 4 bytes
  char c;    // 1 byte
  // Padding: 3 bytes
};

在我们 memset 完后：

如图，无论是执行完 s.a = 'x'; 前后，填充位的值都不可靠。为什么呢，希腊奶。但既然标准这么规定了，就不要依赖这种行为（真不会依赖吗？）

anyway，在我的电脑上：

Is this code valid?

1
2

char arr[5] = { 0 };
auto pastEnd = arr + 10;

What about this one?

1
2

char arr[5] = { 0 };
auto pastEnd = arr + 5;

第一个不合法，第二个合法。但是注意不要这么做

1
2
3

char arr[5];
char *pastEnd = arr + 5; 
char value = *pastEnd;   // ub

Which lines are UB, if any?

#include <iostream>

struct Foo1
{
    int a;
};

struct Foo2
{
    int a;
    Foo2() = default;
};

struct Foo3
{
    int a;

    Foo3();
};

Foo3::Foo3() = default;

int main()
{
    Foo1 foo11, foo12 {};
    Foo2 foo21, foo22 {};
    Foo3 foo31, foo32 {};

    std::cout << foo11.a << std::endl;
    std::cout << foo12.a << std::endl;
    std::cout << foo21.a << std::endl;
    std::cout << foo22.a << std::endl;
    std::cout << foo31.a << std::endl;
    std::cout << foo32.a << std::endl;
}

找了个稍微老一点的 gcc 版本 https://godbolt.org/z/bTE77GEs3

可以观察到 11 21 31 32 全是 ub。

11 12 13 是 ub，这很显然。但 32 为什么是呢？

涉及到 user-provided https://eel.is/c++draft/dcl.fct.def.default 。

根据 c 嘎嘎标准，在类外提供构造函数，这被视为 user-provided 的构造函数，对于 user-provided 的构造函数来说，编译器直接调用该构造函数，不再进行额外的零初始化。

所以，如果类外实现构造函数，最好手动初始化所有成员。

Is this code valid?

struct X { int a, b; };
X *make_x() {
    X *p = (X*)malloc(sizeof(struct X));
    p->a = 1;
    p->b = 2;
    return p;
}

Depends on the C++ version, and whether it is C++ to begin with.

Up until C++17, neither an x object nor an int subobjects are created, and this code is UB.

Starting with C++20, an x object and its int subobjects are implicitly created, and this code is valid.

It always has been valid C code, though.

我以为这是对的（毕竟我只在 c 里面写过这样的代码。

在 c++20 之前，malloc 并不创建对象。访问 p->a 时，该内存地址并没有一个真正的 X 对象存在.对象必须使用 new 显示创建。

如果要正确的写的话：

 *make_x() {
  // Allocate raw memory
  void *mem = std::malloc(sizeof(X));
  if (!mem)
    return nullptr;

  // Use placement new to start the lifetime of X at that address.
  X *p = new (mem) X;

  p->a = 1;
  p->b = 2;
  return p;
}

Is using this function dangerous?

auto foo1()
{
    return "Gotta love C++";
}

What about this one?

auto foo2()
{
    const char *str = "Gotta love C++";
    return str;
}

This one?

auto foo3()
{
    const char str[] = "Gotta love C++";
    return str;
}

Nope, nope, yep.

Why? What’s the crucial difference between these functions? Is there any difference in their types?

Accessing any element of the “array” returned by foo1 and foo2 is fine. Try doing that to foo3 and you’ll get an UB, since you’ll be using an object whose lifetime has ended!

foo1 and foo2 return a pointer to a string that is, roughly speaking, allocated and stored somewhere in the executable at compile time.

The pointer returned by foo3 references the local array str which is initialized by copying that same string. This array is local to foo3 and its lifetime ends once the function has returned, hence the UB.

While modern compilers output a warning, what’s a reliable and somewhat general way to check functions like this?

Mark all these functions constexpr and try using them in a constant evaluated context, like static_assert:

1
2
3

static_assert(foo1()[0] == 'G');
static_assert(foo2()[0] == 'G');
static_assert(foo3()[0] == 'G');

Say, clang outputs:

error: non-constant condition for static assertion
   22 | static_assert(foo3()[0] == 'G');
      |               ~~~~~~~~~~^~~~~~
error: accessing 'str' outside its lifetime
   22 | static_assert(foo3()[0] == 'G');
      |               ~~~~~~~~^
note: declared here
   16 |     const char str[] = "Gotta love C++";
      |                ^~~

What does this print?

struct Evil {
  auto begin() { return std::counted_iterator("Library", 7); }
  friend auto begin(Evil&) { return std::counted_iterator("Core", 4); }
  friend auto end(Evil&) { return std::default_sentinel; }
};

Evil rg;
for (char c : rg) { putchar(c); }
std::ranges::for_each(rg, [](char c) { putchar(c); });

borrowed from Arthur O’Dwyer’s blog, where he also considers this in more detail

输出是 CoreLibrary。

这个应该是一个老生长谈的问题了，不过这里展示的比较隐秘，一般是用 std::swap 来讲解 ADL 和 CPO 的。

CPO 和 tag invoke 是现代 cpp 比较重要的特性，ranges 里面大量使用 cpo 进行实现。

Are these functions different?

int f() {
    int x = 0;
    return *(&x - 1 + 1);
}

int g() {
    int x = 0;
    return *(&x + 1 - 1);
}

f() 会是好函数吗？（

事实上，f 是 ub，而 g 没有问题。

borrowed from Daniil Zhuravlev’s blog, where he explains what language in the C++ Standard makes it UB and shows a proof that function f is fishy

Conclusion

我真是疯了，把这个写完了。你如果问我：“我把这些都学会了，我能变成 cpp 大佬吗”？我觉得不行，毕竟揪着偏门语言特性不放大概率是魔怔人。

累了，放张图。

C++ 的魔法契约： Undefined Behavior

Tue, 13 Jan 2026 20:27:02 +0800

在 C 和 C++ 中，有一个叫做 ub (undefined behavior) 的概念，你也许听说过他，视他为洪水猛兽。但打败敌人的第一步往往需要先了解他，那么首先， ub 是什么呢？

Introduction

标准 ¹上面给出的定义是这样的：

未定义行为，即标准对该程序运行结果不施加任何要求，其运行可以为任何结果，也无需保持一致或给出诊断。换句话说，如果你运行了一个包含未定义行为的程序，那么下一刻，你的程序可能会崩溃，你的内存可能会爆炸，世界有可能被外星人入侵。因为其行为是“未定义的”，所以你无法否认：上面的事件都有可能发生。

如果你还没有认识到 ub 存在的危险性，我们先来看一个经典的代码：

void contains_null_check(int *P) {
  int dead = *P;
  if (P == 0)
    return;
  *P = 4;
}

这个代码看起来人畜无害，但实际上他可能导致外星人入侵。

void contains_null_check(int *P) {
  int dead = *P;  // 动作 A: 解引用 P (读取值)
  if (P == 0)     // 动作 B: 检查 P 是否为空
    return;
  *P = 4;         // 动作 C: 再次使用 P (写入值)
}

在进行 int dead = *p 这个语句时，如果 p == nullptr ，这就是 ub ，一旦 ub 发生，之后的任何行为都不再受标准约束，因此编译器可以把后面的 null check 当作“在所有定义良好的执行路径上都不可能为真”来推理并删掉。当然，编译器也可能在发生 ub 后生成向宇宙广播的代码。

void contains_null_check(int *P) {
  int dead = *P;  // 动作 A: 解引用 P (读取值)
  *P = 4;         // 动作 C: 再次使用 P (写入值)
}

然后再进行死代码消除（DCE）：

事实上，在 gcc 之前的版本，gcc （-O2）不会产生这样的汇编，但是 gcc 15.2 产生了。

这是 Evil 啊~（激动）。

当然，编译器也有可能先进行死代码消除，这导致程序会进行空指针检查：

void contains_null_check(int *P) {
  if (P == 0)     // 动作 B: 检查 P 是否为空
    return;
  *P = 4;         // 动作 C: 再次使用 P (写入值)
}

ub 最可怕的不是“会崩”，而是它让编译器获得了更强的推理权：一旦某条路径触发 ub，优化器就可以把这条路径当作不存在，从而重排、删除你以为必要的逻辑。

更可怕的是，这样的代码放不胜防，因为同样的代码，在 clang 或 gcc 下都有可能正常编译运行，也有可能发生：当编译器升级后，原来跑的好好的程序突然崩溃了。

目前 clang，gcc 对 cpp 一致性支持比较好，至于 msvc，它太坏了。

哪怕是世界上最聪明的程序员，也无法百分百肯定自己不会写出 ub 的代码。

行为类别

事实上，C++ 标准不仅定义了什么是 UB，还构建了一套完整的行为类别（Behavior Categories）。为了搞清楚 UB 的边界，我们需要先理清以下几个标准术语。

术语	Who decides?	编译器行为	确定性	经典案例	后果
Well-defined	Standard	必须严格生成对应代码	100% 确定	`std::vector<int> v;`	程序按预期运行，全平台一致。
Ill-formed	Standard	必须报错 (Diagnostic required)	N/A	`void f(int) { return "s"; }`	编译失败。
IFNDR (Ill-formed, no diagnostic)	Standard	无义务	不确定	违反 ODR 原则；某些模板特化错误	链接错误，或者运行时莫名其妙崩溃。
Implementation-defined	Compiler	必须在文档中说明	确定 (对特定编译器)	`sizeof(long)`；`FILE*` 的底层类型	代码不可移植，但在特定环境下行为稳定。
Unspecified	Compiler	无需说明，甚至无需一致	每次编译可能不同	`foo(unique_ptr(new A), unique_ptr(new B))` 谁先 new？	不要写依赖这种行为的代码，否则难以调试。
Undefined Behavior (UB)	None	无义务，可做任何事	无限的可能「」	数组越界；解引用空指针；有符号数溢出	Nasal Demons。逻辑被删除、死循环、安全漏洞。

我们可以这么理解，对于 well-defined ， ill-formed ，IFNDR 这种由标准进行定义的行为类别来说，其运行结果是唯一确定的，你写下这个代码（比如 println("{}", 1 + 2)），无论是在 windows，linux 还是 mac 上编译运行，他的运行结果都是一样的（都是 3），该报错报错，~~无论是在哪个世界线上，都会导向唯一确定的终结~~。

如果说，well-defined 和 ill-formed 与程序的行为结果是一个严格的一对一的单射，那么，implementation-defined 和 unspecified 就是一对多的有界集合映射。

标准对其规定了，我不保证你结果是唯一确定的，但是你的结果必须要落在我给出的这几个可能结果里面，比如 sizeof(int) ，他可以是 4 也可以是 8，但他不能是 114514 。

对 implementation-defined 来说，其在 x 平台下的行为是会在文档里面准确说明的，但对于 unspecified 来说，其行为就是未知但会落在一个确定的范围里面，比如经典的函数求值顺序 foo(A(), B()) ，他是处于量子态的，可能我今天是先 A 再 B ，明天就可能逆转。但无论如何，在不考虑异常和函数内部的 ub 的情况下，A 和 B 都会执行完成并把返回值传递给 foo。

在 C++17 之前，A 和 B 的执行甚至是可以交错的（比如 A 执行了一半去执行 B）。C++17 规定了求值是 Indeterminately sequenced（不确定顺序），即要么先完整做 A，要么先完整做 B，不再允许交错，但具体谁先谁后依然是 unspecified。

这些行为的结果取决于平台，编译器，硬件等等因素，相同的代码在不同的编译器编译出来的产物运行结果可能不同。

undefined behavior 就如之前所说，你无法知道其行为到底会产生什么结果。

UB 存在的理由

为什么一定要有 ub 存在呢？为什么不像 jvav，py 一样把所有行为定义清楚？这样不就会非常 safe 了？

你说的没错，这样确实会 safe 一些，那么，代价是什么呢？

c++ 是静态编译，对性能非常敏感的语言，其设计原则之一是：零成本抽象（Zero-overhead Principle）。

举一个简单的例子：

void foo(int x) {
	if (x > x + 1) {
		// process x
	}
	// ...
}

编译器假设 x 永远不会发生溢出，因为溢出是未定义行为，在良好定义下，这个语句永远为 false。编译器就有可能，把这个分支判断彻底删除。

在 jvav 等程序中，整数溢出通常被定义为补码回环（Wrap-around），他不允许编译器删除这个 if，这个 if 在特定情形下会被执行。这意味着，每次运行到这里，cpu 都有可能浪费一些时钟周期。如果在循环内，这也会阻止编译器进行 simd 等优化。

正是因为这是一个 ub，所以编译器才会对其进行优化。编译器优化的前提是，程序员不会写出包含 ub 的代码。

换句话说，ub 是编译器和程序员的契约，编译器假设程序员永远不会写出包含 ub 的代码，这样编译器才能够让程序运行的尽可能的快。

这些微小的优化（DCE，RNCE 等等），对性能的影响是巨大的，面对性能和安全这两个永恒的矛盾点，c/cpp 做出了他的 trade off。

其次，程序在理论上和现实上差距是巨大的，现实世界的种种因素导致程序几乎不可能在所有的硬件平台上保持一致性，对于那些不好定义，甚至无法定义的行为，不妨统一归属于 ub，这既方便，又高效。

更多关于 ub 的例子参见 cppreference - Undefined behavior 。

如何检查 ub

cpp 程序员无法避免他写出包含 ub 的代码，所以只能尽可能少些可能包含 ub 的代码，或是使用工具。

笔者未亲自使用过静态分析工具，资料参考自外部。

开启编译器的全部警告，-Wall -Wextra -Werror -Wshadow 等等。
使用静态代码分析工具，clang-tidy cppcheck PVS Studio 等等。
在运行时捕获 ub，也就是所谓的 sanitizers ，比如 asan 抓取内存错误，ubsan 尽可能检查 ub 等等。
尽可能少些可能导致 ub 的代码，遵循编程范式，多用 modern cpp。

Reference

笔者才疏学浅，文章可能存在错误和纰漏，请谨慎阅读。

值得一提的是，在工业界极致的性能优化中，确实存在一些利用‘UB 假设’来辅助编译器生成的黑魔法（例如利用 std::unreachable() 消除分支，或是早年著名 3D 引擎中的 Fast Inverse Square Root 算法）。受限于笔者目前的经验与本文篇幅，这部分高阶内容暂不展开。

准确来说，这是标准 ISO/IEC 14882:2024 的草案 n4950。 ↩︎

C++ Coroutines (1)

Fri, 28 Nov 2025 08:21:14 +0800

这是 Lewis Baker 关于 C++ 协程系列文章的第一篇。

This is the first of a series of posts on the C++ Coroutines TS , a new language feature that is currently on track for inclusion into the C++20 language standard.

这是关于 C++ Coroutines TS 系列博文的第一篇，一个崭新的语言特性正在按计划纳入 C++20 的语言标准。

In this series I will cover how the underlying mechanics of C++ Coroutines work as well as show how they can be used to build useful higher-level abstractions such as those provided by the cppcoro library.

在这个系列中，我将会涵盖 C++ 协程如何工作的底层机制，同时展示如何利用他们构建一个有用的如由 cppcoro 库提供的高层抽象。

In this post I will describe the differences between functions and coroutines and provide a bit of theory about the operations they support. The aim of this post is introduce some foundational concepts that will help frame the way you think about C++ Coroutines.

在这篇博客中，我将会描述函数和协程之间的不同，并且提供一点点他们支持操作的理论。这篇博客的目的是介绍一些基础概念来帮助你形成思考 C++ 协程的方式。

Corountines are Functions are Coroutines

A coroutine is a generalisation of a function that allows the function to be suspended and then later resumed.

一个协程是一个能让函数被挂起然后恢复的泛化函数。

I will explain what this means in a bit more detail, but before I do I want to first review how a “normal” C++ function works.

我将会更加详细的解释这意味着什么，但是在我解释之前，我希望先来复习一下一个 “普通的” c++ 函数是如何工作的。

“Normal” Functions

A normal function can be thought of as having two operations: Call and Return (Note that I’m lumping “throwing an exception” here broadly under the Return operation).

一个普通的函数可以可以被认为有两种操作：Call 和 Return （注意我在这里把 “抛出异常” 归结为广泛的 Return 操作）。

The Call operation creates an activation frame, suspends execution of the calling function and transfers execution to the start of the function being called.

Call 操作创建一个激活帧，暂停调用函数的执行并且转移执行权到被调用函数的开始。

The Return operation passes the return-value to the caller, destroys the activation frame and then resumes execution of the caller just after the point at which it called the function.

Return 操作将返回值传递给调用者，销毁激活帧，然后紧接着在调用该函数的位置之后恢复调用者的执行。

Let’s analyse these semantics a little more…

让我们进一步分析这些语义。。。

Activation Frames

So what is this ‘activation frame’ thing?

所以，这个 “激活帧” 到底是什么呢？

You can think of the activation frame as the block of memory that holds the current state of a particular invocation of a function. This state includes the values of any parameters that were passed to it and the values of any local variables.

你可以把激活帧视作一块维护当前特定函数调用状态的内存。这个状态包括被传入函数的参数的值和其他任何局部变量。

For “normal” functions, the activation frame also includes the return-address - the address of the instruction to transfer execution to upon returning from the function - and the address of the activation frame for the invocation of the calling function. You can think of these pieces of information together as describing the ‘continuation’ of the function-call. ie. they describe which invocation of which function should continue executing at which point when this function completes.

对 “普通” 函数来说，激活帧也包括返回地址 - 即从函数返回后，(CPU) 要执行指令的地址 - 和调用函数此次调用的激活帧地址。你可以认为这些信息共同描述了函数调用的“延续性”。也就是说，他们描述了哪个函数的哪个调用应该在函数完成的哪个位置继续执行。

With “normal” functions, all activation frames have strictly nested lifetimes. This strict nesting allows use of a highly efficient memory allocation data-structure for allocating and freeing the activation frames for each of the function calls. This data-structure is commonly referred to as “the stack”.

对于 “普通” 函数，每个激活帧都有严格嵌套的生命周期。这种严格嵌套的关系，使得高效率内存分配数据结构的分配和释放每个函数调用的激活帧得以成立。这种数据结构通常被称为 “栈”。

When an activation frame is allocated on this stack data structure it is often called a “stack frame”.

当激活帧被分配到这个栈数据结构时，通常被称为 “栈帧”。

This stack data-structure is so common that most (all?) CPU architectures have a dedicated register for holding a pointer to the top of the stack (eg. in X64 it is the rsp register).

这种栈数据结构是如此的常见，以至于绝大多数 CPU 架构都有一个专用的寄存器来保存栈顶指针（如：X64 的 rsp 寄存器）。

To allocate space for a new activation frame, you just increment this register by the frame-size. To free space for an activation frame, you just decrement this register by the frame-size.

为了给新的激活帧分配空间，你只需给这个寄存器的值加上帧大小。为了释放激活帧的空间，你只需给这个寄存器的值减去帧大小。

The ‘Call’ Operation

When a function calls another function, the caller must first prepare itself for suspension.

当一个函数调用另一个函数时，调用者必须先为挂起做好准备。

This ‘suspend’ step typically involves saving to memory any values that are currently held in CPU registers so that those values can later be restored if required when the function resumes execution. Depending on the calling convention of the function, the caller and callee may coordinate on who saves these register values, but you can still think of them as being performed as part of the Call operation.

这个 “挂起” 步骤通常涉及将当前 CPU 寄存器的值保存进内存，以便稍后函数恢复执行时，能够在需要的情况下还原这些值。取决于函数的调用约定，调用者和被调用者也许会协调谁来保存这些值，但你仍然可以将这一过程视为调用操作的一部分。

The caller also stores the values of any parameters passed to the called function into the new activation frame where they can be accessed by the function.

调用者会将被传进被调用函数的参数值储存进一个新的可以被函数访问的激活帧。

Finally, the caller writes the address of the resumption-point of the caller to the new activation frame and transfers execution to the start of the called function.

最终，调用者将调用者的恢复点地址写入新的激活帧，并且转移执行到被调用函数的开始。

In the X86/X64 architecture this final operation has its own instruction, the call instruction, that writes the address of the next instruction onto the stack, increments the stack register by the size of the address and then jumps to the address specified in the instruction’s operand.

在 X86/X64 架构中，这个最终操作有他自己的指令 - call 指令。这个指令将下一个指令的地址写入栈中，给栈指针的值加上地址大小，然后跳转到在指令操作数里面指定的地址。

The ‘Return’ Operation

When a function returns via a return-statement, the function first stores the return value (if any) where the caller can access it. This could either be in the caller’s activation frame or the function’s activation frame (the distinction can get a bit blurry for parameters and return values that cross the boundary between two activation frames).

当函数经过 return 语句时返回时，函数首先把返回值（如果存在）存进一个调用者可以访问的位置。这个位置可以是调用者的激活帧或者函数的激活帧（当参数和返回值跨越两个激活帧的边界时，界限可能会有些模糊）。

Then the function destroys the activation frame by:

Destroying any local variables in-scope at the return-point.

Destroying any parameter objects

Freeing memory used by the activation-frame

然后函数通过以下方式销毁激活帧：

销毁所有在 return-point 作用域内的局部变量。
销毁所有参数对象。
释放激活帧占用的内存。

And finally, it resumes execution of the caller by:

Restoring the activation frame of the caller by setting the stack register to point to the activation frame of the caller and restoring any registers that might have been clobbered by the function.

Jumping to the resume-point of the caller that was stored during the ‘Call’ operation.

最终，调用者通过：

通过设置栈指针指向调用者的激活帧，来还原调用者的激活帧。还原那些可能被函数覆写后的寄存器。
跳转到在 Call 操作中储存的调用者恢复点。

恢复调用者执行。

Note that as with the ‘Call’ operation, some calling conventions may split the responsibilities of the ‘Return’ operation across both the caller and callee function’s instructions.

请注意，与“调用”操作类似，某些调用约定也许会将“返回”操作的责任分割到调用者和被调用者的指令中。

Coroutines

Coroutines generalise the operations of a function by separating out some of the steps performed in the Call and Return operations into three extra operations: Suspend, Resume and Destroy.

协程通过把函数操作内调用和返回的部分执行步骤细分，将其泛化为三个额外的操作：挂起，恢复，销毁。

The Suspend operation suspends execution of the coroutine at the current point within the function and transfers execution back to the caller or resumer without destroying the activation frame. Any objects in-scope at the point of suspension remain alive after the coroutine execution is suspended.

挂起操作在函数内部的当前位置暂停协程的执行，同时在不销毁激活帧的情况下，将执行权转移回调用者 (caller) 或恢复者 (resumer)。在协程执行挂起后，任何在挂起点作用域内的对象都会保持存活。

Note that, like the Return operation of a function, a coroutine can only be suspended from within the coroutine itself at well-defined suspend-points.

注意到如同函数的返回操作，一个协程仅能在协程内部的一个明确定义的挂起点被挂起。

The Resume operation resumes execution of a suspended coroutine at the point at which it was suspended. This reactivates the coroutine’s activation frame.

恢复操作在挂起点恢复执行协程。这重新激活了协程的激活帧。

The Destroy operation destroys the activation frame without resuming execution of the coroutine. Any objects that were in-scope at the suspend point will be destroyed. Memory used to store the activation frame is freed.

销毁操作销毁销毁协程的激活帧，而不再恢复协程的执行。任何在挂起点作用域内的对象都将被销毁。激活帧占用的内存也会被释放。

Coroutine activation frames

Since coroutines can be suspended without destroying the activation frame, we can no longer guarantee that activation frame lifetimes will be strictly nested. This means that activation frames cannot in general be allocated using a stack data-structure and so may need to be stored on the heap instead.

因为协程可以不销毁激活帧挂起，所以我们不能再保证激活帧的生命周期是严格嵌套的。这意味着激活帧通常无法使用栈数据结构来分配内存，因此可能需要分配在堆上。

There are some provisions in the C++ Coroutines TS to allow the memory for the coroutine frame to be allocated from the activation frame of the caller if the compiler can prove that the lifetime of the coroutine is indeed strictly nested within the lifetime of the caller. This can avoid heap allocations in many cases provided you have a sufficiently smart compiler.

在 C++ Coroutines TS 中有些机制，如果编译器能够证明协程的生命周期确实是严格嵌套在调用者的生命周期内部的，可以允许协程帧的内存分配到调用者的激活帧上。只要你有一个足够聪明的编译器，这可以在很多情况下避免堆分配。

With coroutines there are some parts of the activation frame that need to be preserved across coroutine suspension and there are some parts that only need to be kept around while the coroutine is executing. For example, the lifetime of a variable with a scope that does not span any coroutine suspend-points can potentially be stored on the stack.

对于协程，激活帧的某些部分需要在协程挂起期间被保留，而有些部分只需要在协程执行期间存在。例如，如果一个变量的作用域没有横跨任何协程挂起点，那么他就有可能被储存在栈上面。

You can logically think of the activation frame of a coroutine as being comprised of two parts: the ‘coroutine frame’ and the ‘stack frame’.

你可以在逻辑上认为协程的激活帧由两个部分组成：“协程帧”和“栈帧”。

The ‘coroutine frame’ holds part of the coroutine’s activation frame that persists while the coroutine is suspended and the ‘stack frame’ part only exists while the coroutine is executing and is freed when the coroutine suspends and transfers execution back to the caller/resumer.

“协程帧”保存了协程激活帧中在协程挂起期间依然持久存在的那部分数据，而“栈帧”部分仅在协程执行期间存在，当协程挂起并将执行权交还给调用者/恢复者时，这部分就会被释放。

The ‘Suspend’ operation

The Suspend operation of a coroutine allows the coroutine to suspend execution in the middle of the function and transfer execution back to the caller or resumer of the coroutine.

协程的挂起操作允许协程在函数中间暂停执行，并且将执行权转移回协程的调用者或恢复者。

There are certain points within the body of a coroutine that are designated as suspend-points. In the C++ Coroutines TS, these suspend-points are identified by usages of the co_await or co_yield keywords.

在协程的内部有些位置被指定为挂起点。在 C++ Coroutines TS 中，这些挂起点通过 co_await 和 co_yield 关键字识别。

When a coroutine hits one of these suspend-points it first prepares the coroutine for resumption by:

Ensuring any values held in registers are written to the coroutine frame

Writing a value to the coroutine frame that indicates which suspend-point the coroutine is being suspended at. This allows a subsequent Resume operation to know where to resume execution of the coroutine or so a subsequent Destroy to know what values were in-scope and need to be destroyed.

当协程执行到了这些挂起点之一时，它首先会通过以下方式为恢复协程做准备：

确保所有储存在寄存器里面的值被写进协程帧。
向协程帧里面写入一个值，表明在协程里面的哪些一个挂起点正在被挂起。这保证了后续的恢复操作知道协程在哪里恢复执行，或者让后续的销毁操作知道哪些值在作用域内，需要被销毁。

Once the coroutine has been prepared for resumption, the coroutine is considered ‘suspended’.

一旦协程完成了恢复准备，这个协程就被认为是“挂起”。

The coroutine then has the opportunity to execute some additional logic before execution is transferred back to the caller/resumer. This additional logic is given access to a handle to the coroutine-frame that can be used to / later resume or destroy it.

然后协程在执行权被转移回调用者/恢复者之前，有机会去执行一些额外的逻辑。这些额外的逻辑能够访问一个句柄，该句柄后续能被用来恢复或者销毁协程帧。

This ability to execute logic after the coroutine enters the ‘suspended’ state / allows the coroutine to be scheduled for resumption without the need for synchronisation / that would otherwise be required if the coroutine was scheduled for resumption prior to entering the ‘suspended’ state / due to the potential for suspension and resumption of the coroutine to race. I’ll go into this in more detail in future posts.

这种协程在进入“挂起”状态后仍能执行逻辑的能力，允许我们为协程的恢复进行调度，而不需要同步（如果我们为协程恢复调度先于进入“挂起”状态，由于协程潜在的挂起恢复竞争，会导致需要进行同步）。我会在未来的博客进一步深入讨论这个。

The coroutine can then choose to either immediately resume/continue execution of the coroutine or can choose to transfer execution back to the caller/resumer.

随后，协程可以选择立即恢复/继续协程的执行，或者将执行权转移回调用者/恢复者。

If execution is transferred to the caller/resumer the stack-frame part of the coroutine’s activation frame is freed and popped off the stack.

如果执行权转移回调用者/恢复者，协程激活帧的栈帧部分将会被释放，并从栈顶弹出。

The ‘Resume’ operation

The Resume operation can be performed on a coroutine that is currently in the ‘suspended’ state.

恢复操作可以针对当前处于“挂起”状态的协程来执行。

When a function wants to resume a coroutine it needs to effectively ‘call’ into the middle of a particular invocation of the function. The way the resumer identifies the particular invocation to resume is by calling the void resume() method on the coroutine-frame handle provided to the corresponding Suspend operation.

当一个函数想要恢复协程时，他实际上需要‘call’到函数特定调用的中间位置。恢复者识别这种特定的恢复调用的方式是，在那个由相应挂起操作提供的协程帧句柄上，调用 void resume() 方法。

Just like a normal function call, this call to resume() will allocate a new stack-frame and store the return-address of the caller in the stack-frame before transferring execution to the function.

就如普通的函数调用，resume() 的调用会分配一个新的栈帧，并在执行权被转移回函数之前，将调用者的返回地址储存到栈帧里面。

However, instead of transferring execution to the start of the function it will transfer execution to the point in the function at which it was last suspended. It does this by loading the resume-point from the coroutine-frame and jumping to that point.

然而，不同于将执行权转移回函数的开始，这个调用会把执行权转移到函数上一次被挂起的位置。它通过加载协程帧里的恢复位置并跳转到这个位置来实现这个操作。

When the coroutine next suspends or runs to completion this call to resume() will return and resume execution of the calling function.

当协程的下次挂起或运行完成时，resume() 的调用将会返回，并恢复调用函数的执行。

The ‘Destroy’ operation

The Destroy operation destroys the coroutine frame without resuming execution of the coroutine.

销毁操作销毁协程帧，而不恢复协程的执行。

This operation can only be performed on a suspended coroutine.

这个操作仅能在被挂起的协程上执行。

The Destroy operation acts much like the Resume operation in that it re-activates the coroutine’s activation frame, including allocating a new stack-frame and storing the return-address of the caller of the Destroy operation.

销毁操作在重新激活协程帧这一点上，与恢复操作十分类似，这包括分配一个新的栈帧和储存销毁操作调用者的返回地址。

However, instead of transferring execution to the coroutine body at the last suspend-point it instead transfers execution to an alternative code-path that calls the destructors of all local variables in-scope at the suspend-point before then freeing the memory used by the coroutine frame.

然而，不同于将执行权转移到函数上一个挂起点的协程内部，它把执行权转移到另一个代码路径上。在协程帧占用的内存被释放之前，这个代码路径调用挂起点处作用域内所有局部变量的析构函数。

Similar to the Resume operation, the Destroy operation identifies the particular activation-frame to destroy by calling the void destroy() method on the coroutine-frame handle provided during the corresponding Suspend operation.

与恢复操作类似，销毁操作在相应挂起操作提供的协程帧句柄上，调用 void destroy() 方法，来识别将要被销毁的特定激活帧。

The ‘Call’ operation of a coroutine

The Call operation of a coroutine is much the same as the call operation of a normal function. In fact, from the perspective of the caller there is no difference.

协程的调用操作与普通函数的调用操作非常相似。事实上，从调用者的视角来看，这没有任何区别。

However, rather than execution only returning to the caller when the function has run to completion, with a coroutine the call operation will instead resume execution of the caller when the coroutine reaches its first suspend-point.

然而，函数只有运行完成后才将执行权返回给调用者，而协程不同，协程的调用操作会在协程到达第一个挂起点时，就恢复调用者的执行。

When performing the Call operation on a coroutine, the caller allocates a new stack-frame, writes the parameters to the stack-frame, writes the return-address to the stack-frame and transfers execution to the coroutine. This is exactly the same as calling a normal function.

当正在协程中执行调用操作时，调用者分配一个新的栈帧，将参数、返回地址写入栈帧，并转移执行权给协程。这与普通函数的调用是完全相同的。

The first thing the coroutine does is then allocate a coroutine-frame on the heap and copy/move the parameters from the stack-frame into the coroutine-frame so that the lifetime of the parameters extends beyond the first suspend-point.

协程做的第一件事是，在堆上分配一个协程帧，把参数从栈帧复制/移动到协程帧上面，以便参数的生命周期能够延续到第一个挂起点之后。

The ‘Return’ operation of a coroutine

The Return operation of a coroutine is a little different from that of a normal function.

协程的返回操作和普通函数有稍微的不同。

When a coroutine executes a return-statement (co_return according to the TS) operation it stores the return-value somewhere (exactly where this is stored can be customised by the coroutine) and then destructs any in-scope local variables (but not parameters).

当协程执行一个 return 语句（依据 TS 是 co_return）时，它把返回值储存到某些地方（具体在哪些地方可以由协程自定义），然后析构在作用域内的所有局部变量（不包括参数）。

The coroutine then has the opportunity to execute some additional logic before transferring execution back to the caller/resumer.

在转移执行权给调用者/恢复者之前，协程有机会去执行一些额外的逻辑。

This additional logic might perform some operation to publish the return value, or it might resume another coroutine that was waiting for the result. It’s completely customisable.

这些额外的逻辑也许会执行一些操作去发布返回值，或者恢复另一个正在等待结果的协程。这完全是自定义的。

The coroutine then performs either a Suspend operation (keeping the coroutine-frame alive) or a Destroy operation (destroying the coroutine-frame).

然后协程会执行挂起操作（保持协程帧存活）或者销毁操作（销毁协程帧）。

Execution is then transferred back to the caller/resumer as per the Suspend/Destroy operation semantics, popping the stack-frame component of the activation-frame off the stack.

随后，执行权会按照挂起/销毁操作的语义转移回调用者/恢复者，并将激活帧的栈帧部分从栈中弹出。

It is important to note that the return-value passed to the Return operation is not the same as the return-value returned from a Call operation as the return operation may be executed long after the caller resumed from the initial Call operation.

很重要的一点是，传递给 Return 操作的返回值，和 Call 操作的返回的返回值是不一样的，因为 return 操作执行的时间点，可能比调用者从初始 Call 操作的时间点要晚很久。

An illustration

To help put these concepts into pictures, I want to walk through a simple example of what happens when a coroutine is called, suspends and is later resumed.

为了以图解的方式阐释这些概念，我希望带你梳理一些关于协程被调用，挂起，以及稍后被恢复时的简单例子。

So let’s say we have a function (or coroutine), f() that calls a coroutine, x(int a).

假如我们有一个函数（或者协程）f(), 它调用一个协程 x(int a)。

Before the call we have a situation that looks a bit like this:

在调用之前我们的（内存）情况大致如下：

STACK                     REGISTERS               HEAP

                          +------+
+---------------+ <------ | rsp  |
|  f()          |         +------+
+---------------+
| ...           |
|               |

Then when x(42) is called, it first creates a stack frame for x(), as with normal functions.

然后当 x(42) 被调用，它首先为 x() 创建一个栈帧，如同普通的函数。

STACK                     REGISTERS               HEAP
+----------------+ <-+
|  x()           |   |
| a  = 42        |   |
| ret= f()+0x123 |   |    +------+
+----------------+   +--- | rsp  |
|  f()           |        +------+
+----------------+
| ...            |
|                |

Then, once the coroutine x() has allocated memory for the coroutine frame on the heap and copied/moved parameter values into the coroutine frame we’ll end up with something that looks like the next diagram. Note that the compiler will typically hold the address of the coroutine frame in a separate register to the stack pointer (eg. MSVC stores this in the rbp register).

然后，一旦协程 x() 为协程帧在堆上分配了内存，并复制/移动参数值到协程帧里，我们最终得到类似如下图表的情况。注意到编译器通常会把协程帧的地址保存在和栈指针不同的寄存器（eg. MSVC 把这个储存在 rbp 寄存器）。

STACK                     REGISTERS               HEAP
+----------------+ <-+
|  x()           |   |
| a  = 42        |   |                   +-->  +-----------+
| ret= f()+0x123 |   |    +------+       |     |  x()      |
+----------------+   +--- | rsp  |       |     | a =  42   |
|  f()           |        +------+       |     +-----------+
+----------------+        | rbp  | ------+
| ...            |        +------+
|                |

If the coroutine x() then calls another normal function g() it will look something like this.

如果协程 x() 接下来调用了另一个普通函数 g()，情况如下：

STACK                     REGISTERS               HEAP
+----------------+ <-+
|  g()           |   |
| ret= x()+0x45  |   |
+----------------+   |
|  x()           |   |
| coroframe      | --|-------------------+
| a  = 42        |   |                   +-->  +-----------+
| ret= f()+0x123 |   |    +------+             |  x()      |
+----------------+   +--- | rsp  |             | a =  42   |
|  f()           |        +------+             +-----------+
+----------------+        | rbp  |
| ...            |        +------+
|                |

When g() returns it will destroy its activation frame and restore x()’s activation frame. Let’s say we save g()’s return value in a local variable b which is stored in the coroutine frame.

当 g() 返回时，它将会摧毁自己的激活帧，并且恢复 x() 的激活帧。假设我们把 g() 的返回值保存在了储存在协程帧上的局部变量 b 上。

STACK                     REGISTERS               HEAP
+----------------+ <-+
|  x()           |   |
| a  = 42        |   |                   +-->  +-----------+
| ret= f()+0x123 |   |    +------+       |     |  x()      |
+----------------+   +--- | rsp  |       |     | a =  42   |
|  f()           |        +------+       |     | b = 789   |
+----------------+        | rbp  | ------+     +-----------+
| ...            |        +------+
|                |

If x() now hits a suspend-point and suspends execution without destroying its activation frame then execution returns to f().

如果现在 x() 遇到了挂起点并挂起执行，且没有销毁其激活帧，那么执行权会返回给 f()。

This results in the stack-frame part of x() being popped off the stack while leaving the coroutine-frame on the heap. When the coroutine suspends for the first time, a return-value is returned to the caller. This return value often holds a handle to the coroutine-frame that suspended that can be used to later resume it. When x() suspends it also stores the address of the resumption-point of x() in the coroutine frame (call it RP for resume-point).

这导致 x() 的栈帧部分从栈里弹出，而协程帧则保留在堆上。当协程首次挂起时，会将一个返回值返回给调用者。这个返回值通常保存了一个指向挂起的协程帧的句柄，稍后可以用于恢复协程。当 x() 被挂起时，它还会把 x() 的恢复点地址储存在协程帧中（称之为 RP）。

STACK                     REGISTERS               HEAP
                                        +----> +-----------+
                          +------+      |      |  x()      |
+----------------+ <----- | rsp  |      |      | a =  42   |
|  f()           |        +------+      |      | b = 789   |
| handle     ----|---+    | rbp  |      |      | RP=x()+99 |
| ...            |   |    +------+      |      +-----------+
|                |   |                  |
|                |   +------------------+

This handle may now be passed around as a normal value between functions. At some point later, potentially from a different call-stack or even on a different thread, something (say, h()) will decide to resume execution of that coroutine. For example, when an async I/O operation completes.

这个句柄现在也许可以作为普通值在函数之间传递。在稍后的某个时间点，可能是不同的调用栈，甚至是在另一个线程上，某个函数（比如 h()）决定恢复该协程的执行。比如，当一个异步 I/O 操作完成时。

The function that resumes the coroutine calls a void resume(handle) function to resume execution of the coroutine. To the caller, this looks just like any other normal call to a void-returning function with a single argument.

协程恢复函数调用 void resume(handle) 来恢复协程的执行。对调用者来说，这就像其他普通的对 void-returning 单参数函数调用一样。

This creates a new stack-frame that records the return-address of the caller to resume(), activates the coroutine-frame by loading its address into a register and resumes execution of x() at the resume-point stored in the coroutine-frame.

这创建了一个新的栈帧，其中记录了 resume() 调用者的返回地址，通过加载它的地址到寄存器中来激活协程帧，并在储存于协程帧的恢复点处，恢复 x() 的执行。

STACK                     REGISTERS               HEAP
+----------------+ <-+
|  x()           |   |                   +-->  +-----------+
| ret= h()+0x87  |   |    +------+       |     |  x()      |
+----------------+   +--- | rsp  |       |     | a =  42   |
|  h()           |        +------+       |     | b = 789   |
| handle         |        | rbp  | ------+     +-----------+
+----------------+        +------+
| ...            |
|                |

In summary

I have described coroutines as being a generalisation of a function that has three additional operations - ‘Suspend’, ‘Resume’ and ‘Destroy’ - in addition to the ‘Call’ and ‘Return’ operations provided by “normal” functions.

我已经把协程描述为函数的泛化，除了“普通”函数提供的 call 和 Return 操作外，它还有三个额外的操作 - Suspend（挂起），Resume（恢复）和 Destroy（销毁）。

I hope that this provides some useful mental framing for how to think of coroutines and their control-flow.

我希望这能提供一些有用的思维框架，帮助你理解协程及其控制流。

In the next post I will go through the mechanics of the C++ Coroutines TS language extensions and explain how the compiler translates code that you write into coroutines.

在下一篇文章中，我将深入讲解 C++ Coroutines TS 语言拓展的机制，并解释编译器是如何将你编写的代码转换为协程的。

Macro in C/CPP

Wed, 06 Aug 2025 12:36:02 +0800

Around the right track baby we ain’t going back
― Fly To Meteor (Milthm Edit)

Encounter

起因是因为这么一段代码

1
2

#define trace(...) \
    RecursionTracer tracer_##__LINE__(__func__, #__VA_ARGS__, ##__VA_ARGS__)

在我多次调用的时候,出现了如下报错

int f(int x) {
    trace(x);
    if(x == 1) {
        return 1;
    }
    int res = x * f(x - 1);
    trace(x, res);
    return res;
}

clang++ -std=c++23 -g -Wall -Wextra new.cpp -o new
new.cpp:55:5: error: redefinition of 'tracer___LINE__'
   55 |     trace(x, res);
      |     ^
./debug.hpp:213:21: note: expanded from macro 'trace'
  213 |     RecursionTracer tracer_##__LINE__(__func__, #__VA_ARGS__, ##__VA_ARGS__)
      |                     ^
<scratch space>:328:1: note: expanded from here
  328 | tracer___LINE__
      | ^
new.cpp:47:5: note: previous definition is here
   47 |     trace(x);
      |     ^
./debug.hpp:213:21: note: expanded from macro 'trace'
  213 |     RecursionTracer tracer_##__LINE__(__func__, #__VA_ARGS__, ##__VA_ARGS__)
      |                     ^
<scratch space>:326:1: note: expanded from here
  326 | tracer___LINE__
      | ^
1 error generated.
make: *** [Makefile:10: new] Error 1

这个时候我对宏还几近一无所知, 对于这样违背常识的报错感到很困惑. 查阅资料解决问题后便决定写一篇总结。

C Preprocessor

我们知道, 你写下的 C/C++ Code 从源代码到可执行文件一般会经历四个步骤 :

细节可以查阅这篇文章The four stages of the gcc compiler: preprocessor, compiler, assembler, linker.

C preprocessor 是一个 text file processor ( 文本文件处理器 ), 它主要在编译过程的第一个阶段 –预处理阶段– 对源代码文件进行操作，主要提供四个功能¹ :

file inclusion (文件包含)
macro expansion (宏展开)
conditional compilation (条件编译)
line control

不过要注意的是, C preprocessor 仅仅是一个文本处理器, 它并不明白 C/C++ 的语法, 这在很多时候, 会导致一些危险的行为。

Features

File inclusion

C 预处理器中有两个用于包含文件内容的指令 :

#include (source file inclusion ) 。
#embed (resource inclusion )。

Source file inclusion

就是常见的 #include <iostream>, C 预处理器会将 iostream 里面的内容包含到源代码中。

对于标准库和系统级头文件一般使用 <>, 对于本地或者用户自定义的头文件, 则使用 "" . C 预处理器会针对这种形式上的不同使用不同的搜索策略。

Resource inclusion

在 C23 和 C++26 中引入 #embed 预处理指令, 允许你在编译期间将二进制文件的内容嵌入到源代码当中，生成一个静态的常量数组。

Conditional compilation

可以理解成适用 C 预处理器的 if-else 结构.

比如 :

1
2
3

#ifdef VERBOSE
	std::cerr << "trace message" << std::endl;
#endif

相关文档介绍Conditional compilation

Macro string replacement

直观上的来讲, 宏就是一个 snippet 的别名, 在预处理阶段， C preprocessor 会扫描源代码，将所有的宏替换成其预先定义好的内容。

Object-like

object-like macro 定一个别名, 最终预处理器将其替换为实际内容. 它不接受参数, 没有办法实例化. 例如 :

格式为 # define identifier replacement-list new-line

1
2

#define PI 3.14
#define int long long

Function-like

function-like macro 行为类似于函数，定义的宏后面必须紧跟一对括号，不能有空格。支持传入参数, 也可以让参数为空. 例如 :

`1`	`#define MAX(a, b) std::max(a, b)`

Operators

Defined operator

defined 是一个一元谓词, 表示当 ** 宏被定义时, defined 为真, 否则为假.

一下两种方式都可以调用 defined :

1
2

#if defined(MY_MACRO)
#if defined MY_MACRO

Token stringification operator

# 是一个 operator, 代表一个运算, 而不是一个标识. # 将一个标记转化为一个字符串, 并且会自动添加转义符号.比如 :

`1`	`#define str(s) #s`

str(\n) expands to "\n" and str(p = "foo\n";) expands to "p = \"foo\\n\";".

void printFunctionName(std::string s) { 
	//... 
}

void foo() {
	//...
	printFunctionName(#__func__);
}

Token concatenation

也就是 ## , ## 作为一个 operator, 把标记两个标记连接成一个. 也就是把两个字符串拼接. 比如 :

`1`	`#define DECLARE_STRUCT_TYPE(name) typedef struct name##_s name##_t`

DECLARE_STRUCT_TYPE(g_object) expands to typedef struct g_object_s g_object_t.

The Order Of Expansion

除了上面提到过的那些, 还有一些常见的 features, 比如预定义宏, #warning , Line control 之类的。

不过, 这些都不重要！现在我们把目光放回最开始的那个 bug 。

我的本意是想要自动创建一个独一无二的对象, 但是编译器提醒我们, 重复定义了 tracer__LINE__ . 根据编译的报错提示，我们发现，问题的根源在于 __LINE__ 根本没有展开。

接下来就是本节的难点了。

Object-like Macro Expansion

首先来思考这样一个问题，考虑如下代码：

1
2

#define A B
#define B A

在我们使用宏 A 的时候，会不会无限展开下去呢？

答案是肯定不会的。

我们用一个例子来说明 object-like Macro 的递归展开规则：

#define arg1 arg1 | arg2 | arg3
#define arg2 arg1 2
#define arg3 arg2 3

arg1
// 被展开为 arg1 | arg1 2 | arg1 2 3

递归定义禁用集 U 表示：「从递归的上一层的 U 与上一个宏的并集」, 最开始 U 被定义为 $∅$ ，表示当前宏不是被任何其他宏展开得来的。

第一步，arg1 维护的 U 是空集，将 arg1 (1) 展开为 arg1 | arg2 | arg3 (2)，这里对应图里的第一个 expand 。
第二步，我们从左向右扫描，首先遇到 arg1 (2) ，他的维护的集合已经包含了 {arg1} ，那么 arg1 (2) 就不应该被展开，它保持原样。接着遇到 | ，| 不是宏，跳过。然后我们遇到第二个宏 arg2 (2) , 他维护的集合 {arg1} 不包括 arg2 ，arg2 (2) 被展开为 arg1 2 。跳过 | ，展开 arg3 (2) 为 arg2 3 ，此时 arg3 维护的集合变成 {arg1, arg3} 。
第三步，展开从上一个 arg3 继承来的 arg2 (3) ，它维护的集合是 {arg1, arg3} ，将其展开为 arg1 1 。

展开过程结束，最终结果为 arg1 | arg1 2 | arg1 2 3 。

我这图写的稍微有些误导性，需要指出的是，这个 expand 不是像 bfs 那样逐层展开的，而是像 dfs 那样遇到就展开到底部再返回。

可以发现，整个递归过程构成一颗先序遍历的递归树。我们可以用这种方式很好的理解整个 object-like 宏的展开规则。

回到先前的 case ：

1
2

#define A B
#define B A

那么答案就很显然了，依赖于使用的宏是 A 还是 B ，而且只会被展开一次。

Function-like Macro Expansion

function-like 宏以如下顺序展开²:

Stringification operations are replaced with the textual representation of their argument’s replacement list (without performing expansion).
Parameters are replaced with their replacement list (without performing expansion).
Concatenation operations are replaced with the concatenated result of the two operands (without expanding the resulting token).
Tokens originating from parameters are expanded.
The resulting tokens are expanded as normal.

还有一个额外的特性：

每次展开结束后，identifier 会向后看一个 token 判断是否构成一个新的 function-like 宏。³

我们来看几个例子来解释这几个步骤：

#define COMMA ,
#define CALL(f, args) f(args)
#define FUNC(a, b) a - b

CALL(FUNC, 1 COMMA 2)
// 1 - 2

#define EMPTY
#define FOO(a, b) a + b
#define BAR(x)    FOO x

BAR((1, 2))
// 1 + 2

参数优先展开。

首先展开 CALL ，f 对应 FUNC, args 对应 1 COMMA 2 , COMMA 是宏，优先展开为 , ，展开后变成 FUNC(1, 2) 。

每次展开结束后，identifier 会向后看一个 token 判断是否构成一个新的 function-like 宏。

预处理器向后看，发现 FUNC(1, 2) 可以被匹配函数式宏，展开为 1 - 2。

#define STRINGIZE_IMPL(x) #x
#define STRINGIZE(x)      STRINGIZE_IMPL(x)

#define CAT_IMPL(a, b) a##b
#define CAT(a, b)      CAT_IMPL(a, b)

#define VAL 123

// STRINGIZE(VAL) -> "123"
// STRINGIZE_IMPL(VAL) -> "VAL"
// CAT(VAL, VAL) -> 123123
// CAT_IMPL(VAL, VAL) -> VALVAL

参数列表里的参数会被优先展开。但如果该参数在替换列表中被 # 或 ## 所调用，那么该参数不展开。

STRINGIZE(VAL) 被展开为 “123” ，但是 STRINGIZE_IMPL(VAL) 就会先展开为 #VAL 再展开为 "VAL" 。

CAT 同理。

#define A(x) B(x)
#define B(y) A(y)

A(1) 
// A(1)

过程和 object-like 一样，首先 A(1) 的禁用集 (U) 是 $∅$，被展开为 B(1) ， U 中添加 {A} ，接着再展开成 A(1) ，U 中为 {A, B} 终止展开。

U 中元素包含所有从上一次展开的宏，不一定是递归展开的宏。

#define BAR() 1 BAZ()
#define BAZ() BAR
#define FOO(x) BAR() - x()

FOO(BAR())
// BAR() -> 1 BAZ()
// BAZ() -> BAR
// FOO(BAR()) -> FOO(1 BAR) -> BAR() - 1 BAR()
// ...........................U{FOO}...U{BAZ, BAR}
// BAR() - 1 BAR() -> 1 BAR - 1 BAR()
// --- end --- //

理解了以上内容后，我之前遇到的 bug 也就很容易明白错在哪里了，也就是上面 function-like Marco 展开的第二个例子说的。

也很容易修复，利用一个辅助宏，先展开参数再 ## 上去就行了。

#define TRACE_EXPAN(counter) tracer_##counter
#define TRACE_HELPER(counter) TRACE_EXPAN(counter)

#define trace(...) \
    RecursionTracer TRACE_HELPER(__COUNTER__)(__func__, #__VA_ARGS__, ##__VA_ARGS__)

variadic macro

__VA_ARGS__ 比较简单，需要需要注意的是使用的时候应该加上 ## :

这是为了防止传入参数个数为 0 的时候，, 剩余。使用 ## 可以把这个 , 吞掉。

1
2
3

#define LOG(fmt, ...) printf(fmt, ##__VA_ARGS__)
LOG("User %s", "Alex") // -> printf("User %s", "Alex");
LOG("System started."); // -> printf("System started.");

在 gcc 拓展中，实现了一个宏 __VA_OPT__ 表示一个参数是 optional 的，于是上面的代码可以改成：

`1`	`#define LOG(fmt, ...) printf(fmt __VA_OPT__(,) __VA_ARGS__)`

表示如果 ... 不为空，就在这里插入一个 , 。

Delayed expansion

#define A() 123

#define EMPTY()
#define DEFER(id) id EMPTY()
#define EXPAND(...) __VA_ARGS__

DEFER(A)()
EXPAND(DEFER(A)())

考虑 DEFER(A)() 宏，当他展开到 A EMPTY()() 的时候，EMPTY() 被展开，此时结果为 A () ，注意这一轮扫描已经结束了。在 DEFER(A)() 这一次宏展开的重新扫描过程中，A 和 () 无法构成一次函数式宏调用，因此展开被延迟了。注意在此时 A () 被展开成 A () 的前一时刻的 U 是 {DEFFER, EMPTY} ，但是当生成 A () 后，U 被销毁，重新变成空集。

当我们给这个宏的外面再套一层壳的时候，EXPAND() 宏使得预处理器重新扫描 A () ，它被识别为一个函数式宏，展开成 123 。注意这个时候 A () 的 U 被消除了，展开完后的 U 是 {A} 而不是 {DEFFER, EMPTY, A} 。

我们在这里重新提到了禁用集 U ，是因为它在接下来这个魔法中发挥了至关重要的作用。

A Little Magic

#define BAR_I() BAR
#define BAR() 1 BAR_I

BAR () () () // U {}
-> BAR_I () () // U {BAR}
-> BAR () // U {BAR_I} 注意！在执行上一步的展开时，U 被消除了
-> BAR_I // U {BAR} 此处也消除了上一轮的 U

也就是说，每当我展开过程中出现一个新的 function-like 宏时，这个新的 function-like 宏不会继承它源头的 U 。

我们利用刚才的延迟展开，可以实现以下代码：

#define BAR_I() BAR
#define BAR()  DEFER(BAR_I)()() 1

BAR()                 -> BAR_I()() 1
EXPAND(BAR())         -> BAR_I()() 1 1
EXPAND(EXPAND(BAR())) -> BAR_I()() 1 1 1

这说明宏可以构成一个有限的递归栈，进而说明了宏是图灵完备的。

以上代码来自于宏定义黑魔法-从入门到奇技淫巧 (5) - 实现图灵完备的宏。

X-Macros

假设我们有一个结构体 User ，我们需要将它序列化为 JSON 字符串，也要能够从 JSON 字符串中解析出来。

struct User {
    std::string name;
    int         id;
};

我们的目的是自动生成下面功能的函数

void toJSON (const User &user, std::ostream &os);
void fromJSON (User &user, const JsonObj &json);

我们创建一个 userMembers.def 文件，列出 User 结构体的所有成员。

// userMembers.def
// X(type, name)
X(std::string, name)
X(int,           id)

在我们的主代码中：

#include ...
// 各种头文件包含

struct User {
#define X(type, name) type name;
#include "userMembers.def"
#undef X
// serMembers.def 的内容被展开后，立马 undef X，自动生成了结构体 User 。
};

void toJSON (const User &user, std::ostream &os) {
	os << "{";
	bool first = true;
#define X(type, name) \
	if (!first)  { os << ","; } \
	os << "\"" << #name << "\":" << json_quote(user.name); \
	first = false;
// 宏定义结束

	#include "userMembers.def"
// userMembers.def 里面的内容被自动展开为上面的内容
// 比如 ：
// Expands to  
// if (!first) {  
// os << ",";  
// }  
// os << "\"" << "name" << "\":" << json_quote(user.name);  
// first = false;
// if (!first) {  
// os << ",";  
// }  
// os << "\"" << "id" << "\":" << json_quote(user.id);  
// first = false;

#undef X
	os << "}";
}

void fromJSON (User &user, const JsonObj &json) {
#define X(type, name) json.get_to(#name, user.name);
	#include "userMembers.def"
#undef X
}

通过 X 宏，可以实现自动生成结构体，自动生成对应的解析函数，唯一要做的修改就是在 userMembers.def 里面添加或删除变量。

// userMembers.def
// X(type, name)
X(std::string, name)
X(int,           id)
X(int,        score)

Macros FAQ

Operator Precedence

1
2
3

#define SQUARE(x) x * x

int result = SQUARE(3 + 2);

我们期望得到结果 5 ，但是实际上得到是 3 + 2 * 3 + 2 。

Repeated Evaluation of Arguments

#define MAX(a, b) ((a) > (b) ? (a) : (b))

int x = 5;
int y = 8;
int z = MAX(x++, y++);
// x 期望是 6, y 期望是 9, z 期望是 8

但实际上宏在展开的过程中 x++ ， y++ 都出现了两次，这个行为是未定义的，结果未知，但肯定和期望值不同。

Name Clashes

宏的定义是全局的，这就很容易造成命名冲突。

不过在 c++20 中，引入了模块化来解决 #include 和宏所带来的全局污染问题。

Semicolon Swallowing

#define LOG(msg) printf("%s\n", msg);

if (condition)
    LOG("It was true");
else
    do_something_else();
    
// if (condition)
//     printf("%s\n", "It was true");;
// else
//     do_something_else();

当然你也可以在第一个分支里选择不加分号，不过这种别扭的行为还是禁止的为好。

常用的技巧是使用 do-while(0) 语句来形成一个完整的语义。

#define LOG(msg) \
    do { \
        printf("%s\n", msg); \
    } while(0)

// 展开后:
// if (condition)
//     do { ... } while(0); // 这是一个单一的语句，需要一个分号
// else
//     ...

宏还有一些缺点，比如无法调试，阅读困难等等。现有的序列化和反序列化，枚举转化为字符串，ORM 等等操作都需要借助宏来实现，标准库的源代码也总会有宏的身影。总的来说，宏并不是一个很好的东西，但他也是一个不可或缺的东西。在现代 cpp 中，可以使用 template , constexpr 等等来替换宏，但仍然有很多地方宏是不可被替代的。这就是为什么 c++26 的反射被那么多人期待。

References

参考自维基百科 ↩︎
参考自维基百科 ↩︎
宏定义黑魔法-从入门到奇技淫巧 (3) - function-like 的宏展开 ↩︎

C++ 杂项

Sat, 24 May 2025 22:40:03 +0800

$Part\ I.$

Static Variables in a Function

可以认为，声明在函数中被直接初始化的静态变量，就相当于把变量声明在全局，但是静态变量的作用域仅仅在函数内部其作用。

Static Member Variables in a Class

在类里面声明的静态变量分配空间时只被分配一次，所以类中所有实例化的对象中的静态变量相同，也就是静态变量和所有对象共享。也正是因为这个原因，静态变量不能使用构造函数进行初始化。

#include <iostream>
using namespace std;

class GfG {
public:
  
  	// Static data member
    static int i;

    GfG(){
        // Do nothing
    };
};

// Static member inintialization
//int GfG::i = 1;

int main() {
  
    // Prints value of i
    cout << GfG::i;
}

1
2
3

/tmp/ccPusLB5.o: In function `main':
Solution.cpp:(.text.startup+0xd): undefined reference to `GfG::i`
collect2: error: ld returned 1 exit status

编译器在编译阶段为可能存在的 int GfG:: 打上引用，因为编译器假设 GfG::i 的定义会在其他地方提供，然而链接的阶段并没有找到为 GfG::i 分配空间的地方，所以抛出一个引用错误 undefined reference to GfG::i

Static Member Function in a Class

类似的，静态成员函数只能调用静态变量，被所有类共享。

Global Static Variable

全局静态变量具有内部链接，也就是对于链接器来说，全局静态变量是看不见的，他只能被当前的翻译单元所访问，可以用来防止其他相同名字的其他文件变量冲突。注意定义在头文件中的静态变量作用域也被限制在当前的翻译单元，也就是对所有引用头文件的翻译单元来说，每个翻译单元都有一个静态变量的副本

Static 修饰的变量或者函数，导致的性质就是他的作用域会被改变，要想理解 static 关键词，应该先对程序的编译过程有一定的认识。

参考链接

$Part\ II.$

$Tag\ Dispatch$

// C++ Program to show the implementation of
// tag dispatch
#include <bits/stdc++.h>
using namespace std;

// Creating the different tags of type empty
// struct
struct t1{};
struct t2{};

// Defining a function for type t2
void fun(int a, t1) {
    cout << "Calling function of tag t" << 
      a << endl;
}

// Defining the function with different 
// implementation for type t2
void fun(int a, t2) {
    cout << "Function with tag t" << 
      a << endl;
}

int main() {

    // Function calling with different tags
    fun(1, t1{});
    fun(2, t2{});
  	return 0;
}

标签调度，其实是利用函数重载的一种 c++ 技巧，可以用来处理这样一种情况：你要做出不同的操作对具有相似参数和返回值的同名函数。

这是一种静态多态($static\ polymorphism$)

参考博客

$Part\ III.$

$Duff's\ Device$

#include <iostream>
#include <vector>
#include <numeric>

void copyIntArray(std::vector<int>& src, std::vector<int>& dest, int size) {
    int rounds = size / 8;
    int i = 0;

    switch(size % 8) {
        case 0: 
            while(rounds-- > 0) {
                dest[i] = src[i++];

                case 7 : dest[i] = src[i++];
                case 6 : dest[i] = src[i++];
                case 5 : dest[i] = src[i++];
                case 4 : dest[i] = src[i++];
                case 3 : dest[i] = src[i++];
                case 2 : dest[i] = src[i++];
                case 1 : dest[i] = src[i++];
                    
            };
    }
}

int main () {
    int size = 20;
    std::vector<int> src(size, 0), dest(20);

    std::iota(src.begin(), src.end(), 1); 

    copyIntArray(src, dest, size);

    for(int i = 0; i < size; ++i) {
        std::cout << dest[i] << std::endl;
    }
        
    return 0;
}

利用 switch 语句的特性进行非常奇怪的操作，这被叫做 $Duff's\ device$，可以用来模拟 C++ 的协程，但是在 C++20 版本已经提供了官方封装的协程。

How does Duff’s Device work?

$Part\ IV.$

#pragma once

#include <optional>
#include <stdexcept>

/*
 * A Ref<T> represents a "borrowed"-or-"owned" reference to an object of type T.
 * Whether "borrowed" or "owned", the Ref exposes a constant reference to the inner T.
 * If "owned", the inner T can also be accessed by non-const reference (and mutated).
 */
template<typename T>
class Ref
{
  static_assert( std::is_nothrow_move_constructible_v<T> );
    // Type Trait : 模板 T 是否是可移动构造的？
    // _v : 获取类型特性模板类中 :: value , 在 c++17 之前 ，通过 std::is_nothrow_move_constructible<T>::value
  static_assert( std::is_nothrow_move_assignable_v<T> );

public:
  // default constructor -> owned reference (default-constructed)
  Ref()
    requires std::default_initializable<T>
    : obj_( std::in_place )
  {}

  // construct from rvalue reference -> owned reference (moved from original)
  Ref( T&& obj ) : obj_( std::move( obj ) ) {} // NOLINT(*-explicit-*)

  // move constructor: move from original (owned or borrowed)
  Ref( Ref&& other ) noexcept = default;

  // move-assignment: move from original (owned or borrowed)
  Ref& operator=( Ref&& other ) noexcept = default;

  // borrow from const reference: borrowed reference (points to original)
  static Ref borrow( const T& obj )
  {
    Ref ret { uninitialized };
    ret.borrowed_obj_ = &obj;
    return ret;
  }

  // duplicate Ref by producing borrowed reference to same object
  Ref borrow() const
  {
    Ref ret { uninitialized };
    ret.borrowed_obj_ = obj_.has_value() ? &obj_.value() : borrowed_obj_;
    return ret;
  }

#ifndef DISALLOW_REF_IMPLICIT_COPY
  // implicit copy via copy constructor -> owned reference (copied from original)
  Ref( const Ref& other ) : obj_( other.get() ) {}

  // implicit copy via copy-assignment -> owned reference (copied from original)
  Ref& operator=( const Ref& other )
  {
    if ( this != &other ) {
      obj_ = other.get();
      borrowed_obj_ = nullptr;
    }
    return *this;
  }
#else
  // forbid implicit copies
  Ref( const Ref& other ) = delete;
  Ref& operator=( const Ref& other ) = delete;
#endif

  ~Ref() = default;

  bool is_owned() const { return obj_.has_value(); }
  bool is_borrowed() const { return not is_owned(); }

  // accessors

  // const reference to object (owned or borrowed)
  const T& get() const { return obj_.has_value() ? *obj_ : *borrowed_obj_; }

  // mutable reference to object (owned only)
  T& get_mut()
  {
    if ( not obj_.has_value() ) {
      throw std::runtime_error( "attempt to mutate borrowed Ref" );
    }
    return *obj_;
  }

  operator const T&() const { return get(); } // NOLINT(*-explicit-*)
  operator T&() { return get_mut(); }         // NOLINT(*-explicit-*)
  const T* operator->() const { return &get(); }
  T* operator->() { return &get_mut(); }

  explicit operator std::string_view() const
    requires std::is_convertible_v<T, std::string_view>
  {
    return get();
  }

  T release()
  {
    if ( obj_.has_value() ) {
      return std::move( *obj_ );
    }

#ifndef DISALLOW_REF_IMPLICIT_COPY
    return get();
#else
    throw std::runtime_error( "Ref::release() called on borrowed reference" );
#endif
  }

private:
  const T* borrowed_obj_ {};
  std::optional<T> obj_ {};

  struct uninitialized_t
  {};
  static constexpr uninitialized_t uninitialized {};

  explicit Ref( uninitialized_t /*unused*/ ) {}
};

template<typename T>
static Ref<T> borrow( const T& obj )
{
  return Ref<T>::borrow( obj );
}

$Q \& A$

static_assert 是做什么用的？为什么这里要检查 std::is_nothrow_move_constructible_v<T> 和 std::is_nothrow_move_assignable_v<T>？如果 T 类型不满足这些条件会怎么样？
默认构造函数 Ref() 后面的 requires std::default_initializable<T> 是什么意思？它和普通的构造函数有什么区别？
std::optional<T> obj_ 和 const T* borrowed_obj_ 这两个成员变量是如何协同工作来表示 “owned” 和 “borrowed” 状态的？为什么不直接用一个指针和一个布尔标志位？
struct uninitialized_t {}; static constexpr uninitialized_t uninitialized {}; 和私有构造函数 explicit Ref(uninitialized_t) 这一套组合的目的是什么？为什么 borrow 函数需要这样创建一个 Ref 对象？
#ifndef DISALLOW_REF_IMPLICIT_COPY ... #else ... #endif 这段预处理指令是用来做什么的？为什么会有允许或禁止隐式拷贝的选项？拷贝构造函数和拷贝赋值运算符在 “owned” 和 “borrowed” 状态下是如何工作的？
operator const T&() const 和 operator T&() 这两个类型转换运算符为什么没有 explicit 关键字 (注释中提到了 NOLINT(*-explicit-*))？它们允许什么样的隐式转换，这在实际使用中会有什么好处或潜在风险？
T release() 函数在 Ref 是 “owned” 和 “borrowed” 状态时行为有什么不同？为什么在 “borrowed” 状态下（如果 DISALLOW_REF_IMPLICIT_COPY 被定义）会抛出异常？std::move(*obj_) 的作用是什么？
文件末尾的自由函数 template<typename T> static Ref<T> borrow(const T& obj) 和类内部的静态成员函数 static Ref borrow(const T& obj) 有什么区别？为什么会提供一个自由函数版本？这里的 static 用在自由函数模板上是什么意思？
除了类型转换运算符，代码还重载了 operator->() 和 operator->() const。这两个箭头运算符的重载允许我们像使用指针一样使用 Ref 对象（例如 ref_obj->member_func()），它们是如何实现这一点的？在 “owned” 和 “borrowed” 状态下，它们分别返回什么？

以上问题由 Gemini 生成。

C++ on Anfsity

You Dont Know Cpp and Neither I Do

Assigning to references

Defaulted equality

Specialization fun

requires-constrained return types

Is this valid?

Some covariance (协变)

constexpr string literals

When is this function safe or unsafe to use?

Maps of non-copyable, non-movable types

Incrementing enums

operator new

How are these two functions different?

Is this code valid?

(^=…=^)

Conceptual concepts

Fun with fun templates

I C memset

Is this code valid?

Which lines are UB, if any?

Is this code valid?

Is using this function dangerous?

What does this print?

Are these functions different?

Conclusion

C++ 的魔法契约： Undefined Behavior

Introduction

行为类别

UB 存在的理由

如何检查 ub

Reference

C++ Coroutines (1)

Corountines are Functions are Coroutines

“Normal” Functions

Activation Frames

The ‘Call’ Operation

The ‘Return’ Operation

Coroutines

Coroutine activation frames

The ‘Suspend’ operation

The ‘Resume’ operation

The ‘Destroy’ operation

The ‘Call’ operation of a coroutine

The ‘Return’ operation of a coroutine

An illustration

In summary

Macro in C/CPP

Encounter

C Preprocessor

Features

File inclusion

Source file inclusion

Resource inclusion

Conditional compilation

Macro string replacement

Object-like

Function-like

Operators

Defined operator

Token stringification operator

Token concatenation

The Order Of Expansion

Object-like Macro Expansion

Function-like Macro Expansion

variadic macro

Delayed expansion

A Little Magic

X-Macros

Macros FAQ

Operator Precedence

Repeated Evaluation of Arguments

Name Clashes

Semicolon Swallowing

References

C++ 杂项

$Part\ I.$

$Part\ II.$

$Part\ III.$

$Part\ IV.$

`requires`-constrained return types

`constexpr` string literals

`operator new`

I C `memset`