“事了拂衣去” —— 关于return的无尽缠绵

2024-12-13

一个最为简单的return x;语句是C++中出现频率最高的语句之一。为了将这一语句的效率发挥到极致，历代C++都在其上下了极大功夫。

不就是一个return嘛？

是的，确实就是一个return。

C语言的所有变量都符合现代C++的trivial types的定义，即当一个变量被赋值时，只需要将该值对应内存空间的数据简单地copy到当前变量对应的内存空间。
对于 trivial 的类来说，return确实只是将变量的值丢回到函数栈存储返回值之处（随后再销毁其它局部变量等等）。

但C++作为一门面向对象的编译期语言，其揭示了一点——这一表面风平浪静的过程实则暗藏汹涌。
因为某一片具备数据、可使用的内存距离C++中的“对象”概念完全不能相提并论。

这也是C/C++对于堆内存分配的“看法”迥异之处：C的malloc/free实际上不会对内存做任何事情（只是“申请”并获得使用权），顶多算上calloc的零初始化；

而C++中的new实际上涉及分配内存->调用构造函数两步，具体地，你可以认为operator new就是一个calloc加上一个thiscall函数的调用：
1
2
3
4
5
6
7
8
9
10
11
template<class Ty>
Ty* operator new(size_t size) //C++中operator new的最常用函数重载，在隐式调用时size_t会自动传递
{
    Ty* ptr = static_cast<Ty*>(malloc(size));

    //随后，我们假设一个函数的ctor在调用时实际上具备Ty::Ty(Ty* where,...)的形式。
    //其就是将本来隐式传递的this写成了显式的形式，参考python中的self和C++23的deducing this。
    Ty::Ty(ptr);

    return ptr;
}

return背后的风云及传统C++的“应付”之策

现在我们假设希望去返回一个值，在C语言中由于并没有明确的“对象”概念——即使是struct也无异于具有特殊内存layout的fundamental types而已；
因此在返回时，可以直接从源内存块复制数据到目标内存块，随后释放源内存块的内存占用（栈/堆皆然）。以一个对应用途的、比较知名的C函数来说就是可以单纯地memcpy。

C语言中确实有memmove这一函数，但其与C++的移动语义云云无关——其只是提供了在源内存和目标内存重叠时，保证数据可以正确覆写的保证。

而在C++中却不是这样：对象可以认为是内存之上的上层建筑，获得对象时要先分配内存再调用构造函数，销毁对象时需要先调用析构函数再释放内存。
由此，直观的return解决方案就应运而生：以return的值作为参数，分配新内存并构造新对象，随后析构原对象、释放原内存即可。
但对于存在大型类的C++，如此做的弊端也非常明显：

（复制）构造函数、析构函数可能会涉及到大量的其它操作，时间、资源开销较大；
C++的OOP思想决定了资源是由对象所“拥有”的，涉及到保有资源对象的相关操作时，或存在大量不必要的复制-析构操作（如堆内存），或很难/无法依此法安全地完成资源所有权的转移（如文件句柄）。

举个有趣的实例：不知各位在初学C++，观察复制构造函数的作用时，是否有思索——即使是一念间，下面这段函数有些蹊跷？

#include<iostream>
class S
{
public:
    S(int _x):x(_x){}
    S(const S& from):x(from.x * 2){}
    S(S&& from):x(from.x*3){}
    ~S(){std::cout << x << ' ';}
private:
    int x;
}

S single()
{
    return S{1};
}

S transfer()
{
    S w{single()};
    return w;
}

int main()
{
    S a{transfer()};
    return 0;
}

事实上，即使到了C++23，依然无法绝对把握地预测上述代码的输出——（在遵循标准下）不同的编译器给出的不同优化结果都会导致输出不同。
这也是纷争来源之始端：只要拥有non-trivial的复制/移动构造函数（甚至不涉及赋值，涉及赋值更麻烦），就有很多的胡来优化空间。
比如，single()返回的S到底是要copy一次返回（传统C++）还是move一次返回（C++11）？（剧透：C++17起，single()必须遵循 prvalue sematics ,意即其既不会copy也不会move~~(surprise!)~~
再比如，transfer()明明初始化w后啥都没干，返回的时候是copy，还是move，还是都不调用？

从C++98的观点来看（忽略移动构造函数），single()返回时需要复制构造一次，transfer()返回时亦然，故std::cout应当输出1 2 4。

但其实即使是C++98的编译器编译运行之，依然不一定会输出上述结果。

C++11："move sematics comes to the rescue"吗？

其中，第二条也是C++的一大痛点，因而C++11提出了右值引用和移动语义的概念，语言层面上支持了我们通过函数等来完成转移资源的操作。
作为配套，C++11提出了 move-eligible 这一概念，通过它来规范一种"Automatic Move"。

以下标志着一个具有自动存储周期(automatic storage duration)变量的表达式都是 move-eligible （可移动）的：
- 其为一个非易失(non-volatile)对象类型，或一个非易失对象的右值引用（此项C++20中加入）；
- 且其在函数体内被声明/作为函数体内的参数出现。

从C++11开始，对于return x;这条语句用于初始化一个临时对象时，其规定调用构造函数的重载决议会执行两次：
- 第一次决议将x视为一个右值(rvalue?)；但若第一轮重载决议失败，或其成功但未选择移动构造函数（所谓选择函数的形参不是纯粹的“右值引用”），则继续执行第二轮
- 第二次决议时，x就会被视为一个左值(lvalue)。

这里可见的最大的疑点就在第一轮重载决议的“失败”定义。比如，选到= delete;的函数算不算失败？若有多个函数的形参复合要求且优先级相同（即制造了歧义(ambiguity)），是遵循此条规则进行第二轮重载决议还是直接报错？
不同版本中，不同编译器都给出了诸多不同的实现、决策方式。

关于C++11——C++20的规则细讲，可以参考cppreference。
两轮重载决议带来的最大问题就是很多奇特的现象，主要出在所谓“未选择移动构造函数”上。

下述代码中，f1()在C++23前不能通过编译，f2()则通过隐式转换“逃过一劫”：

struct T{};
struct U
{
    U(T&&){}
};

T&& f1(){return T{};}
U f2(){return T{};}

C++11起，由于第一轮重载决议会先将up看作右值，因此可以调用移动构造函数初始化返回值。
C++11以前，若通过一些其它方式禁用了up的复制构造，则其将不能被返回：

std::unique_ptr<int> f3()
{
    std::unique_ptr<int> up{};
    return up;
}

C++20前若第一轮重载决议没有选择移动构造函数（必须是“move constructor”），则会回退到传统C++的重载决策(rr视为左值)进而无法使该段程序ill-formed：

std::unique_ptr<int> f4(std::unique_ptr<int>&& rr)
{
    return rr;
}

C++23：终究利落地斩断万缕过往

对于二次重载决议的纷争不休，C++23最终选择给出了一个干净利落的解决方案：移除此前搭建的诸多为了保证兼容性而留下的设施，最大化"Automatic move"的适用范围。
C++23起，只要return exp;中的exp是 move-eligible 的，那么该表达式就会被视为 xvalue 。当然，如此做也有一定的副作用：

int& fun()
{
    int x = 1;
    return x;
}

这段代码一直以来都是C++中演示悬挂引用(dangling reference)的完美示范，而C++23起这段代码将不能通过编译（因为x将被视作xvalue）。
~~（当然，如果你执意要创造一个悬挂引用，可以把返回值类型改成int&&）~~

预告：C++26中对于上述悬挂引用的规定作出了更新，现在若一个函数返回的引用值绑定至临时对象上，则该程序非良构(ill-formed)。~~相当于悬挂引用return渐渐成为历史~~

NRVO/URVO：C++优化之谜

回到最开始的那个函数套娃传递的实例（不要笑——这种套娃传递初始化构造是非常常见的），在许多场景下其编译结果依然有优化空间：
与其让编译器调用几次移动构造函数，不如甚至直接略去这个过程，让最上层的栈函数直接控制最底层函数构造的对象栈空间。
事实上，早在移动语义提出之前的C++98，就已经允许了编译器执行这样的优化（“优化”掉部分return函数中对可能带副作用的复制构造函数的调用）。

这样的优化场景有两种：
- 返回值的表达式是一个纯右值(prvalue)表达式，称为"URVO"(Unnamed Return Value Optimization)；
- 返回值的表达式是一个本地变量的表达式，但编译器可以预知该变量在一定代码块内不会变化（相当于可以“预判”其返回值/状态），称为"NRVO"(Named Return Value Optimization)。

std::string getstr(int var)
{
    return std::format("{0} {0} {0}",var);
}

std::string process()
{
    std::string base = getstr(3);
    //...
    return base;
}

int main()
{
    std::println("{}",process());
    return 0;
}

如上，C++23中在没有任何优化的情况下，至少需要调用std::string的移动构造函数两次。
但实际上getstr(int)函数中初始化一个对象后直接return了，显然它的栈空间是可以复用的；同时process()中并没有对base进行任何其它操作就直接返回，因而其移动也可以省略。

C++17提出了 prvalue sematics 的概念，要求编译器对纯右值表达式（包括潜在需要隐式调用转换构造函数的返回值）进行复制省略优化（一定不会调用移动/复制构造函数）。对于以下代码：

class Test
{
public:
    Test(){}
    Test(const Test&){std::println("copy ctor");}
    Test(Test&&) noexcept {std::println("move ctor");}
};

int main()
{
    auto v = []{return Test{};}();
    return 0;
}

C++17的 prvalue sematics (a.k.a. guaranteed copy elision) 保证了上述代码不会有任何输出。

但对于NRVO来说，有两个指导于实践中的要点：
1. C++只是允许了这种optimization的存在，对其优化程度则未做任何规定/明确，最终优化/编译结果亦因编译器及编译设置而异：
比如将上述代码中main函数的第一行改为

1	auto v = []{Test t{}; return t;}();

此时程序运行输出可能为空也可能不为空。

严格来说，C++23前这段代码的输出很大程度上取决于v的初始化声明方式（参见“两轮重载决议”）。
C++23保证了这段代码若有输出，则一定是"move ctor"。

NRVO的返回值不能有任何修饰（必须只是一个变量名）。因此return std::move(local)是不被建议的写法（如此做会disable NRVO）。
C++23前，在部分返回引用/move-only类型时可能需要用std::move来保证一定的兼容性，但随着C++23统一将 move-eligible 的本地变量视为xvalue，现在依然建议绝大部分场景直接return local;即可。

std::string ret()
{
    std::string val{};
    //...
    return val; //Left room for NRVO Optimization: invocation of move ctor not necessary
    //return std::move(val); //Try not to code this: surpresses NRVO
}

结语

C++23起，return x;的诸多用法和语义得以被归一化；
从程序设计的角度来说，除少数需要移动一些volatile、static等变量的场景，其它情况下均使用最简单的return x;即可获得最大效率。

无论是学习编程语言，还是学习、工作与生活中处理各种问题，都尽量应当摒弃"take it for granted"的思维。
对一些司空见惯之现象深入探究，方能助自身视野格局突破惰性之樊笼，逐渐得以游走自如于空阔之境。

展开全文 >>

C++20四大金刚之青龙concepts

2024-12-12

东方青龙，concepts龙腾四海。

C++20的更新量级极大：其开创了大量新的编程模式，引入了大量语法点、标准库等等，对C++体系的影响可以与C++11相提并论。
其中更有“四大金刚”——concepts、modules、ranges和coroutines。本篇将深入浅出地探讨concepts这一大特性。
~~其实concepts是C++20最“简单”的大特性之一了~~

Past——SFINAE

concepts其实并不是一个新的“概念”(???)。

模板（泛型）编程的课题可以占据C++的半壁江山。极高的设计自由度、一望无际的复用可能性、牵扯到的语法之繁杂、相关库的多样性使其一直以来都是C++语言的最重要课题，几乎没有之一。
所谓“C++其实是两门语言，带template的是一种，不带template的是另一种”的说法丝毫不为夸张。

而作为一门编译型语言，在Metaprogramming中我们自然希望对模板的参数有一定约束，让函数按设计者期望的方式进行调用。
而在传统C++中，除了一些语言上的小“华点”被复用，并没有太好的办法对模板参数进行高可读性、易于维护/复用、明确的约束。

C++11中提出了SFINAE(Substitution Failure Is Not An Error)的概念。
SFINAE在模板编程中的应用在于完成模板参数替换（即将实例化）时，如果代入Ty = ...会产生一些非法的表达式，则编译器会放弃这个重载（而不是继续试图~~在绝路上狂奔~~编译错误），转而试着寻找下一个重载进行匹配。
与SFINAE相搭配的内容还有：

对于全特化(full specialization)/偏特化(partial specialization)的模板类，其与满足条件（可自动推导）的模板参数匹配优先级很高，且绑定后不会受SFINAE影响放弃。
C++中，对于自动模板参数，其推导遵循最简原则（即优先尝试将令参数不带任何 cvref 修饰来实例化）。

~~（感觉又噎着了，赶紧上代码润润嗓子）~~
最简推导原则：

//完美转发的场景
template<class Ty>
void fun(Ty&& arg);

int x = 2;

fun(1); //Ty = int，虽然Ty = int&&同样“能用”，但最简原则，不加引用优先
fun(x); //Ty = int&（比较显然，毕竟int就不能编译了）

//一些其它的函数调用
template<class Ty>
void bar(Ty arg);

bar(1); //Ty = int，虽然Ty确实可以是int&&，依然是“避重就轻”
bar(x); //Ty仍然是int，虽然Ty依然可以是int&，但毕竟int arg{x};是合法的，所以编译器不会“闲着没事干”

//std::forward
template<class Ty>
std::remove_reference_t<Ty>& forward(std::remove_reference_t<Ty>& arg) noexcept
{
    return arg;
}

常见的非法表达式：

（实例化代码中）建立了对void的引用；

试图对void或其它 不完整的类型 计算sizeof；

试图访问类的某个typedef或静态成员等，但该成员不存在；（SFINAE中最为常用之者）

C++中，在<algorithm>的老STL算法库中经常能看到std::enable_if_t的声明，其封装了std::enable_if这一struct。

C++中一定要分清模板函数的重载(overload)和特化(specialization)两个概念。特化有全特化(full specialization)和偏特化(partial specialization)两种。
模板函数只有“重载”和“全特化”，模板类只有“全特化”和“偏特化”。
对于模板函数，C++在匹配参数时若发现一个模板函数存在重载，则按照以下步骤决策：
- 先判定函数列表是否匹配，排除不匹配的重载选项；
- 若重载选项中一个是模板函数，一个是非模板函数，且非模板函数的形参列表和当前参数不需要隐式转换时，选择非模板函数；
- 否则，若可以通过自动匹配模板函数来令模板函数的形参列表和当前参数匹配，且不需要隐式转换时，选择实例化一个模板函数；
- 否则认为是存在歧义而编译失败。

注意：任何template的声明（变量、函数、类）无论基本还是特化，自身都不会产生任何编译代码；必须有调用方实例化之时，编译的程序才会有这部分代码（比如对于函数来说，存在指向该函数的指针）。
核心点就是特化(specialization)和实例化(instanitation)是不同的概念。
相对地，任何非template的声明则都会产生编译代码（除非在Release版本中被编译器优化掉）。


template<class Ty>
void fun(Ty){} //fun没有任何可执行代码

template<>
void fun<int>(int){} //fun至此仍然未产生任何可执行代码，因为这只是一个模板函数的特化，不是实例化

int main()
{   
    fun('o'); //实例化了一个fun<char>，至此程序中拥有了一个指向函数fun<char>的函数指针
    fun(2.3); //同理
}

模板类则有全特化和偏特化之分，标志为是否是template<>。
一旦出现template<>，说明其指定了模板的全部参数，则为全特化，否则为偏特化。 C++匹配模板参数时，若该模板存在特化，则匹配优先级为全特化>偏特化>基本模板，其即为<type_traits>中诸多utility的实现支撑原理之一。
且C++的模板参数匹配遵循最简原则（无需隐式转换的原始类型优先级最高，引用、指针、const/volatile修饰等优先级后置）。

<type_traits>中提供了一个remove_reference_t封装remove_reference，来在模板编程中获取一个类型名移除引用信息的结果：

template<class Ty>
struct remove_reference
{
    using type = Ty;
};

template<class Ty>
struct remove_reference<Ty&>
{
    using type = Ty;
};

template<class Ty>
struct remove_reference<Ty&&>
{
    using type = Ty;
};

template<class Ty>
using remove_reference_t = typename remove_reference<Ty>::type;


static_assert(std::is_same_t<remove_reference_t<int&>,int>); //注意比较类型不能用operator==

Present——concepts？

C++20与"concepts"有关的关键字有两个：concept和requires。其中，
- concept声明一个“概念”，其本质是一个编译期的模板bool变量。其必须作为一个模板变量声明，并以编译期常量(compile-time constant)初始化之。如：

template<class Ty>
concept example = true; //一个永远为真的concept
//其实它的本质就是
template<class Ty>
constexpr bool equivlant_cpvar = true;

template<class Ty>
concept small = sizeof(Ty) < 4; //对于sizeof()小于4的类型，获得一个true的编译期常量

static_assert(small<int>);
static_assert(!small<double>);

requires则既可以作为specifier修饰一个模板（进行约束），亦是定义concepts元素的一部分。

requires作为约束提示字

作为前者时，其可以出现在template的多种可能位置~~（C++20为了避免过多争端，对各方势力采取绥靖政策而接受了多种不同写法）~~。
通过requires显式约束时，变量可以是一个concept或编译期的bool变量：

//#1
template<class Ty> requires(small<Ty>)
class smallvector{};

//#2
template<class Ty> void func(Ty arg) requires(small<Ty> && std::is_nothrow_destructible<Ty>)
//Main body can be omitted(just declaration)
{

}

而隐式约束时，其必须是一个concept~~（所以可能需要对一些旧的interface手动套皮）~~。
对于单模板变量的约束，其空置变量数必须为1（具体地，实例化时会将该模板参数填入该concept的第一个模板参数中，若其仍有后续非默认参数则必须指定之）：

template<class Tx,class Ty>
concept two_template_parameters = true;

template<two_template_parameters<int> Ty> //相当于约束 two_template_parameters<Ty,int>
void func(){}

C++14起大幅扩大了auto的适用范围，约束auto模板变量的方法也非常奇怪简单：

void func(std::default_formattable<char> auto x)
{

}J

requires作为concepts一部分

requires可以发起一个子句，语法是requires (init_params){...}。
其中，init_params为可选项，如果加上了括号，则其中可以放置一些参数（如同写出函数的实参一样），可在下面的内嵌约束中使用。大括号内可以添加任意数量的内嵌约束语句(nested constraints)，以分号分隔且存在逻辑与的关系（当且仅当内嵌约束全部满足时，该requires解析为true）。 Nested constraints的分类如下：

简单约束：一个任意的表达式，该表达式合法（可以通过编译）时通过；
变量约束: requires加上一个编译期的bool变量，该变量为true时通过；
复合约束：语法为{expr} (noexcept) (-> [concept])，通过条件如下：
1. expr必须能通过编译（和“简单约束”相同）；
2. 若声明了noexcept，则expr必须被声明为noexcept(true)；
3. 若指定了后继的-> [concept]（所谓"trailing type"-后继类型），则按以下的步骤校验：
  - 将decltype(expr)代入至后继的concept中（作为第一个变量，规则可以参考模板隐式约束），
  - 该concept也必须最终解析为true。
上述任何一个步骤失败，则该约束的解析结果为false。

应用实例：

//比如现在约束一个迭代器类，要求：
//1. 其必须可以与同类对象比较并返回bool，且不能抛出异常；
//2. 其必须支持（前置）自增和自减运算；
//3. 其必须可以解引用并返回一个int&；
//4. 其大小必须不大于8。
template<class Ty>
concept biint_iterators = requires(Ty it) //这里“幻化”出了一个变量it，可以在下文约束中使用。
{
{it != it} noexcept -> std::same_as<bool>;
++it; --it;
{*it} -> std::same_as<int&>;
requires sizeof(it) < 8;
};

显然concepts的约束比起SFINAE等方法可读性、维护性提升了数个数量级。

展开全文 >>