C++——Structured Binding

2025-08-13

翩若惊鸿，矫若游龙。

Structured Binding，即“结构化绑定”，是C++17中引入的颇为强大的语法糖之一。

前言

阅读本章需要道友具备对右值引用、移动语义、基本模板编程的相关知识与较好理解基础。

由于C/C++只允许单个返回值，因而C/C++中需要从函数中“获取”多个值时，除了传递可变指针/引用~~所谓OUT变量(bushi)~~，利用最多的方法无疑就是返回一个struct或std::pair/std::tuple了：

struct ret_info
{
    int x;
    std::string dt;
    const char* c;
};

ret_info func();

如此做的最大缺点之一就是访问每个成员不够便利——一个成员还能通过~~生命周期冲突百出的~~临时子成员访问，但访问多个成员时就必须另起一个变量接收之：

1
2
3

auto st = func();
int y = st.x;
std::println("{}",st.dt);

同时还可能涉及到 cv 修饰符差分、引用绑定等问题。
由此，C++17给出了 Structured Binding 这个极为强大的语法糖用于处理此类情景。

正题

首先明确 Structured Binding 的基本属性，一言具述之：

Like a reference, a structured binding is an alias to an existing object; unlike a reference,a structured binding does not have to be of a reference type.

即结构化绑定和引用相比，皆为既有对象的别名；但前者不一定是引用类型。

基本语法

Structured Binding的语法如下：

attr decl-specifier ref-qualifier [identifier-list] initializer ;

各部分解析：

attr：任意数目的属性(attributes)
decl-specifier：依下列顺序出现的修饰符（与变量声明规则一致）：static、thread_local、const、volatile、auto；其中auto必须出现
ref-qualifier：可选&/&&或置空
[identifier-list]：变量名列表
initializer：初始化表达式

显然其中重中之重的关键字无疑是auto——Structured Binding的类型不能手动指定，只允许使用auto并以一定的修饰符约束之。

中间变量初始化

initializer 中的expr可为任意表达式，与普通变量的初始化类似（除未加括号的逗号表达式，即 unphrenthesized comma expressions ）：

= expr;
(expr);
{expr};

回顾结构化绑定的本质：其为一个既有对象的别名，初始化方式只有两种。首先引入一个隐式、不具名而唯一的变量e（参考 lambda）：

若 initializer 是一个数组类型且 ref-qualifier 置空，记 initializer 的类型为 cv1 A，则定义e为形如 attr decl-specifier（去除auto） A e; 的新数组（即decl-specifier std::remove_cvref_t<decltype(initializer)> e;，此处不计属性）；随后将 [identifier-list] 的各元素依 initializer 中的各元素复制/直接初始化（若为= expr则为复制初始化，否则为直接初始化）；
否则，定义e形如 attr decl-specifier ref-qualifier e initializer。

const auto [a,b,c] = {1,2,3};  //the implicit `e` is `const std::initializer_list<int>`  

int[] arr = {1,2,3};
const auto [d,e,f] = arr; //the implicit `e` is `const int[3]`, with each element in `e` copy-initialized from arr's corresponding elements
const auto& [m,n,p] = arr; //the implicit `e` is `const int(&)[3]`(derived from `const auto&`,i.e. a reference to an array)  

char ch{};
std::tuple<int&,char&&,std::string> tp{arr[0],ch,""};

const auto [r,s,t] = tp; //the implicit `e` is `const std::tuple<int&,char&&,std::string>`(derived from `const auto`)
//Thus `r` is `int&`,`s` is `char&&`,`t` is `const std::string`

const auto& [r2,s2,t2] = tp; //the implicit `e` is `const std::tuple<int&,char&&,std::string>&`(derived from `const auto&`)
//Thus `r2` is `int&`,`s2` is `char&&`,`t2` is `const std::string&`

//const auto [y] = (2); //Error: the implicit `e` is `int`, which cannot be 'binded'
//const auto [x,y] = (1,2); //Same as above

理解消化上述类型推导的代码实例对于理解、通晓 Structured Binding 的类型逻辑至关重要——建议各位道友自行举例并多加推导之。

应用

Structured Binding 中的变量有三种初始化方式，取决于右操作数的类型E（严格地，std::remove_reference_t<decltype((e))>）：

E是数组类型；
E是一个非union的class/struct，且std::tuple_size<E>是具备数据成员value的完整类型（complete type），无论std::tuple_size<E>::value的变量类型、可访问性(accessibility)如何；
E是一个非union的class/struct，除情况2外的其它类型。

称情况(2)采用的是类元组绑定法(tuple-like binding)；情况(3)则绑定至其可访问的数据成员上。

数组绑定法(binding to an array)

此种情况比较简单，即 Structured Binding 声明的每个变量名就是数组对应元素的别名(alias)。
由于这个数组是“虚拟”的中间数组，因此这些变量就是原始类型而非引用，但其底层存储的逻辑依然不变（连续存储，下同）：

int[] arr = {1,2,3};
const auto [d,e,f] = arr;
//since the implicit `e` is `const int[3]`,thus `d`,`e`,`f` refers to the three elements of `e` respectively,
//with their type being `const int`,and address incrementing by 4
const auto& [m,n,p] = arr;
//since the implicit `e` is `const int(&)[3]`, thus `d`,`e`,`f` refers to three elements of `arr` respectively
//with their type being `const int&`

//In both cases, the three variables' values are 1,2,3

类元组绑定法(tuple-like binding)

类元组绑定法的基础是存在成员std::tuple_size<E>::value，所谓“实现了元组操作”(implemented tuple operations)。

首先，std::tuple_size<E>::value必须是良构(well-formed)的整型常量表达式，此时 Structured Binding 的大小与之一致。

即使std::tuple_size<E>::value不符合上述条件，但只要存在此成员（无论类型、可访问性），则编译器均会采用此方式进行绑定——纵使如此会令程序非良构(ill-formed)而不能通过编译。

对于 Structured Binding 中的第I个数据成员，其类型为std::tuple_element<I,E>::type &&，即底层类型为左值则为左值引用，否则为右值引用（参考 引用折叠/reference collaspe）。

其初始化表达式如下：

若类E存在名为get的成员模板函数，且首个参数是常量模板参数(constant template parameter)，则为e.get<I>()；
否则为std::get<I>(e)，其中get仅考虑ADL(Argument-Dependent Lookups)。

变量的生命周期与e一致，配合 lifetime extension 等保证了一般情况不会出现悬挂引用(dangaling reference)的情况。

同样地，此处的重载决议不会考虑get如此是否会令程序非良构，即使template<char*> void get();亦会使编译器选择使用第一种“解读”方式~~进而编译错误~~。

仔细观察下列实例，必以求甚解为通晓之策：

char ch{};
std::tuple<int&,char&&,std::string> tp{arr[0],ch,""};

const auto [r,s,t] = tp;
//`E` is `const std::tuple<int&,char&&,std::string>` (derived from `const auto`), initialized from tp
//Thus this derives to that, `r` is `int&` ,`s` is `char&&`,`t` is `const std::string`
//With r referencing same variable as std::get<0>(tp),s to std::get<1>(tp), t being a separate constant std::string object

const auto& [r2,s2,t2] = tp; 
//`E` is `const std::tuple<int&,char&&,std::string>&`(derived from `const auto&`), initialized from tp
//Thus `r2` is `int&`,`s2` is `char&&`,`t2` is `const std::string&`
//With r still referencing to std::get<0>(tp), s to std::get<1>(tp), t is a const l-ref to std::get<2>(tp)

auto&& [r3,s3,t3] = tp;
//`auto&&` introduces a universal reference, in this case `e` derives to `std::tuple<int&,char&&,std::string>&` 
//Thus `r3` is `int&`, `s3` is `char&&`, `t3` is `std::string&`
//Referencing logic is identical to the case as above

可见隐式“中间变量”e的存在是关键：前缀无论存在各种 attributes 、cvref 修饰符，作用对象都是这个中间变量e而非 Structured Binding 自身引入的标识符。
因而可以发现即使是const auto的结构化绑定，引入的变量亦可以是普通的引用类型。

数据成员绑定法(accessible data member binding)

此时 Structured Binding 的对象是e的所有非静态数据成员，待绑定的变量数与其非静态数据成员的个数一致。

在声明结构化绑定的上下文(context)中，e.name语句必须是良构的（即必须满足可访问性限制等，如不可为非友元的private）。

绑定后，各结构化绑定成员（即新引入的变量）都是该中间变量e中各数据成员的别名（关于e的各成员初始化见上文），初始化顺序为e->各绑定成员（按声明顺序）。

划重点：本质上，每个绑定成员都是e的各成员的左值别名，但这个别名不会呈现引用属性（虽然指代的是同一个对象）。考虑以下实例：

#include <iostream>

struct F
{
    std::ostream& o;
};

int main()
{
    F f{std::cout};

    auto [a] = f; //Type of `a` is `std::ostream`, NOT `std::ostream&`
    assert(std::addressof(a) == std::addressof(std::cout)); //passes
    //a is an alias of data member `e.o`(with `e` being an implicit variable), `e.o` initialized by `f.o`
    //Then `e.o` refers to `std::cout`, thus `a` itself IS `std::cout`

    //In other words, references are alias to existing object, yet so are structured bindings.
}

注释

Structured Binding 的类型必须被“自动”推导，不允许被 concepts 约束(constrained)：

template<class>
concept C = true;

C auto [x,y] = std::pair{1,2}; //Error: Constrained

有趣的是这里面涉及到的类模板实例化写法，亦是C++17引入的——C++17起类模板满足条件时允许依构造函数实参推导模板参数，如上例就会推导为std::pair<int,int>。
C++17前，由于只有函数模板才可以自动推导参数，因此~~历史遗留~~下来的std::make_pair、std::make_tuple等就是适配彼时语言机制的产物：

1
2
3
4
5
template<class Ty1,class Ty2>
std::pair<Ty1,Ty2> make_pair(Ty1 arg1,Ty2 arg2)
{
    return std::pair<Ty1,Ty2>(arg1,arg2);
}

前行

C++20

C++17中lambda不能捕获 Structured Binding 初始化的变量，C++20解除了此限制。

int[] arr = {1,2};
auto [x,y] = arr;
auto fn = [x,y]{return x+y;}; //OK Since C++20
assert(fn() == 3);

C++26

C++26将新时代的“可变参数”概念进一步拓展，使 structured binding 也获得了“可变”绑定的能力。
此前所述，接收并初始化的变量数必须和待绑定对象数一致；但C++26起允许将最后一个变量名以前置...而变为一个可变参数包，其类型是一个std::tuple，类型参数同样在编译期即被决定，其大小最小为0：

int[] arr = {1,2,3};

auto [...pack] = arr; //pack is `std::tuple<int,int,int>`
auto [a,b,...pack2] = arr; // a is `int`,b is `int`,pack2 is `std::tuple<int>`
auto [x,y,z,...pack3] = arr; //OK: pack3 is `std::tuple<>`
auto [m1,m2,m3,m4,...pack4] = arr; //Not compile: too few values to be unpacked

展开全文 >>

C++——俗语集锦

2025-08-02

杏花疏影里，吹笛到天明。

C++中有许多~~脍炙人口、妇孺皆知~~的俗语，其是C++程序设计者间“会心一笑”的载体，更蕴含了C++乃至大量编程语言的设计哲学。

RAII

全称 Resource Acquisition Is Initialization，数据获取即初始化。

其基本概念在于对每个需要“申请”资源（所谓 acquired before use，即使用前必须显式“请求”，如堆内存、文件标识符、数据库连接、互斥锁等）的C++对象，其均在构造函数中初始化它们，并在析构函数中将之释放。
结合变量的生命周期机制、移动语义等工具，其目标有两点：

该对象完成初始化（构造时不抛出异常）后，可认为其使用的资源一定被正确地初始化过而“放心”地使用；
无论为何该对象的生命周期结束（包括函数执行结束、提早return、抛出异常等等），该对象获取的资源一定能正确地释放，且无需显式管理之。

以内存管理为例，与手动管理动态数组相比，std::vector的优越性一目了然：

void foo(int*);
void bad()
{
    int* ptr = new int[10]; //?
    foo(ptr); //?

    //...

    if(ptr[0] < 0)
    {
        return; //?
    }

    delete[] ptr; //?
}

void good()
{
    std::vector<int> vc(10);
    foo(vc.data());

    if(vc[0] < 0)
    {
        return;
    }
}

上述代码中，bad函数在许多代码中堪称司空见惯，但其在内存管理上实际上漏洞百出。

若内存申请失败（不论malloc或operator new，虽然后者在多数实现中失败时会抛出异常，但亦需考虑一些行为默认“加了”std::nothrow_t的场景），空的ptr就这么成为“漏网之鱼”被继续使用了。类似的还有fopen（无效的FILE*）、各种数学运算后（无效结果）不检查errno；当然错误处理这块在C++23中也被开辟了“第三赛道”，即以std::expected打头的新时代 sum-types
若foo函数抛出异常而触发栈回溯(stack rewinding)，则ptr对应的内存空间将不会被delete[]释放而泄露~~这里都不考虑ptr传进去所有权(ownership)不明确导致的潜在double-free等问题~~；
若ptr[0]<0，则触发了 early return，在大型的、存在多个出口(return)的函数中，在每个return前都分别delete[]显然不可行，产生的内存漏洞原理同上；
只有当程序运行到delete[] ptr;时，ptr对应的内存才被释放。然而如此做依然有诸多漏洞——若ptr的值中途被更改了，将会如何？若ptr对应的内存已经被~~不小心~~释放过了呢？

相比之下，std::vector封装了“动态数组”头指针及长度，在构造函数中申请堆内存并检查是否成功，并在析构函数中释放之。如此做保证了以下数点：

std::vector的对象初始化成功（可用）是该对象底层指针可用的充分条件，无需担心初始化问题（若分配内存失败，则抛出异常并触发栈回溯，该std::vector的变量即因离开其范围(scope)而不可用；
无论以何种方式离开该变量的生命周期（即其所在的函数执行中止，包括正常完成、抛出异常和 early return 等），该std::vector都会将自身获得的堆内存释放；
通过恰当地声明移动构造函数/赋值运算符，对移动语义的践行到位，使得堆内存资源所有权清晰且易于管理（移动vector时，新对象的指针、长度置为当前对象的对应值，当前对象的数据值置空）。

应用侧闲谈

cppreference也给出了在应用侧使得RAII类的语义、作用能正确发挥的实践方法：

将之声明为自动存储周期(automatic storage duration)的变量，即不以static、thread_local等修饰的、自身在栈上的变量；
或使之与一个具备自动存储周期/临时对象相绑定（如，作为另一个类的非静态数据成员）。

核心观点在于令其构造（初始化）和析构（销毁）均自动进行；同时应避免手动“接管”资源，不改变其既有所有权的语义（如避免调用智能指针的release()）。

C++中典型的 RAII-Classes 包括标准库的容器(Containers)类，如std::vector、std::deque、std::string等；还包括它们衍生的 容器适配类(container adaptors) （在采用的底层容器符合RAII原则的情况下），如std::priority_queue等；亦有用户自定义资源的适配器，如std::lock_guard、std::ostream一族、std::unique_ptr等。

典型的 Non-RAII Classes 即为仅具有lock()/unlock()、open()/close()等一对“手动”获取/释放相应资源的类（映射到堆内存即为operator new/operator delete等）。RAII-Classes 也可以主动申请/释放资源，但底层过程是被封装、自动调用且安全的，如vector的reserve()和clear()。

设计侧简述

设计侧除了让函数应当满足上述申请/释放资源的要求外，语法上还应具备以下几个特点：

构造函数、复制构造函数/赋值运算符若申请资源失败，应当抛出异常以触发顶层函数的栈回溯，进而“阻止”该对象的初始化；
析构函数不应抛出异常，即必定为noexcept；
移动构造函数/赋值运算符亦不应抛出异常（更准确地，遵守完整且正确的移动语义）。

C++中析构函数默认均被标记为noexcept，即只要不显式声明/解析为noexcept(false)的析构函数均为noexcept。编译器自动生成的移动构造函数（含= default;）也是noexcept的，但用户自定义的移动构造函数并不会自动成为noexcept，应手动声明之以高效利用语言库和工具——详见C++——右值引用和移动语义

自定义一个简单的MyVector类的示例如下：

class MyVector
{
    MyVector():ptr(nullptr),length(0)
    {

    }
    MyVector(const MyVector& rhs):ptr{new int[rhs.length]},length(rhs.length)
    {

    }
    MyVector(MyVector&& rhs) noexcept : ptr(rhs.ptr),length(rhs.length)
    {
        rhs.ptr = nullptr;
        rhs.length = 0;
    }

    ~MyVector() //noexcept by default
    {
        if(ptr) //Can be eliminated for deleting nullptr is safe
        //Yet keep this conditional statement for consistant sematics for RAII in other resources' management
        //i.e. File descriptors checking whether it's open(active) before closing it
        {
            delete[] ptr;
        }
    }
private:
    int* ptr;
    size_t length;
};

Rule-of-Three/Five/Zero

对右值引用和移动语义尚不熟悉的道友，建议先移步C++——右值引用与移动语义以更好地理解如此设计的必要性。

基本知识

“3”“5”“0”指代对象是类的析构、复制构造、复制赋值、移动构造、移动赋值五个函数。

先看编译器的“默认”处理方式：

从编译器的角度出发，
- 若自定义了复制构造函数/复制赋值运算符，则编译器将不生成移动构造函数/移动赋值运算符；（注意，此时std::move等对右值的使用不会报错，只是无法发挥移动语义的优势；且此时编译器仍然会默认生成“复制”的另一半）
- 若自定义了移动构造函数/移动赋值运算符，则编译器将不生成复制构造函数/复制赋值运算符，亦不会生成“移动”的另一半；
- 若类存在任意自定义构造函数（包括上述的复制/移动构造函数），则编译器将不生成默认构造函数；

重点：显式地将函数主体声明为= default也算自定义。

上述语言机制对语义上的约束也非常明显：

不允许只定义移动/复制构造函数，而不定义（普通）构造函数，即移动/复制语义不能基于缺省的初始化语义；
若一个类自定义了复制语义的实现，则应当自定义移动语义的实现（不存在缺省值，若不然，则依靠引用绑定机制，移动语义会退化为复制语义）；
若一个类自定义了移动语义的实现，则必须自定义复制语义的实现（不存在缺省值，否则该类的复制语义默认不可用，即视为= delete;）。

上述分析站从C++的较顶层出发，或较抽象而难以理解，尽可能自行设计、思考模拟一个实例的语义实现，或将之实例化“降维”理解—— Beyond 者皆见仁见智。

回到正题：

Rule of Three：若类自定义了 (user-defined) 析构、复制构造/赋值运算符三个函数中的任意一个，则语义上其必须定义剩下两个函数（所谓 it almost certainly requires all three）。
Rule of Five：若类需要利用移动语义进行优化，则在上述基础上还应定义移动构造函数/赋值运算符，即“凑够五行”。
Rule of Zero：若可能，尽量不自定义任何的这五类函数，即让编译器自动生成之。

三清——Rule of Three

何为如此？

铺垫：可以认为每个C++的class都是资源与数据（可以只有一者）的集合。二者皆无的情况下类的对象不存在OOP意义下的实际意义，仅供语法特性适配之用，如泛滥至极的 tag types（标签类型）和 C++20ranges中大面积应用的 function object 。
“数据”本身是 trivial （平凡）的，其包括C++中所有的基本类型，即各类普通类型（各种浮点/整型/bool；enum/enum class是特殊的整型）和指针类型等。“数据”的特点是没有特殊的移动语义，即移动与复制相同（简单地进行内存复制，参考汇编中的mov亦不会改变原地址的值），且不存在“析构”这一概念~~逝以飘零~~。
“资源”可以参考上述的描述。

对于 Rule of Three，若需要自定义析构函数，说明该类中存在需要手动清理的资源/善后工作；则该类的复制构造/赋值必不可能是平凡(trivial)的——即不可能是像C的struct那样，简单地将数据复制到新的内存中。若不然，则该类的资源将同时被多个对象所有且不可区分，极易出现资源管理的疏漏。
如下，C++复制构造函数“入门”的经典踩坑实例就完美地诠释了这一点：

class BadString
{
public:
    BadString(const char* s):ptr(new char[strlen(s) + 1])
    {
        std::strcpy(s,ptr);
    }
    ~BadString()
    {
        delete[] ptr;
    }
private:
    char* ptr;
};

BadString类必须自定义析构函数以释放申请的堆内存。但其未定义复制构造函数，直接导致不能正确地实现复制语义（按照默认的复制构造函数进行，新对象和原对象会指向同一块堆内存），结果自然而然就是 double-free 导致的段错误：

int main()
{
    BadString a("ni hao");
    BadString b(a);

} //Program collaspes here - Segment Fault for double-free(XD)

因此其必须自定义复制构造函数/复制赋值运算符，正确地为新对象重新分配堆内存资源、执行复制操作等。

一定程度上，复制赋值可以视为对象内部“析构-重新复制构造”的过程。但C++不将之和上述过程混为一谈，除因部分场景下复制赋值可以有更高效的实现外（如两个vector大小相同，此时赋值显然直接执行数据复制即可，无需进行释放-再申请的过程），更多地是为了规避开一个非常无趣的应用场景——“自导自演”。
没反应过来咩？欢迎收看2026春节小品之~~我与我周旋久(bushi)~~

class MyVector
{
public:
    //...

    MyVector& operator=(const MyVector& rhs)
    {
        if(std::addressof(*this) == std::addressof(rhs))
        {
            return *this; //......
        }

        if(length != rhs.length)
        {
            delete[] ptr;
            ptr = new int[rhs.length];
            length = rhs.length;
        }
        std::memcpy(ptr,rhs.ptr,length);
    }

    //...
private:
    int* ptr;
    size_t length;
};

反过来，若一个类不需要自定义析构函数也能正确地管理资源（通常通过封装的类实现，或其根本没有资源），则为之编写自定义的复制构造函数和复制赋值运算符也大概率没有意义（均可以通过语言内置的默认复制实现，参考下述的 Rule of Zero 。

五行——Rule of Five

“五行”者对应的动机也很简单，即利用语言的重载匹配机制来让右值能得到优化。
因在 Rule of Three 中，自定义三个函数之一会令编译器不生成默认的移动构造函数/赋值运算符。
尽管此时多数情况下不会出现编译错误~~除非把复制函数族给= delete;~~，但此时类对右值实参会“退化”到调用复制构造函数/赋值运算符（常引用绑定至右值），错失了优化良机：

class BadClass
{
public:
    BadClass() = default;
    BadClass(const BadVector&) = default;

    //...

private:
    std::string s;
    //...
};


void fun()
{
    BadClass x;
    BadClass y = std::move(x);  
    /*This line Invokes BadClass::BadClass(const BadClass&) 
    rather than BadClass::BadClass(BadClass&&) since it's deleted implicitly
    resulting in unable to take advantage of move sematics*/
}

fun第二行中，对象y在初始化时会调用复制构造函数BadClass::BadClass(const BadClass&)而非移动构造函数BadClass::BadClass(BadClass&&)。
尽管二者都是默认生成的，但后者在初始化时会对所有变量进行“移动”处理（即适配移动语义，无论其底层实现如何），如对于下图的类模板：

template<class Ty1,class Ty2>
class A
{
public:
    //...

private:
    Ty1 a;
    Ty2 b;
};

则对模板类A<Ty1,Ty2>，其默认生成的复制构造函数和移动构造函数就会形如：

1 2	A<Ty1,Ty2>::A(const A& rhs):a(rhs.a),b(rhs.b){} A<Ty1,Ty2>::A(A&& rhs):a(std::move(rhs.a)),b(std::move(rhs.b)){}

严格地后者应为static_cast<Ty1&&>(rhs.a)（因语言核心特性不依赖标准库），std::move只是标准库的提高可读性的wrapper~~虽然有std::move的时候没人会闲着没事干让static_cast满天飞~~

若定义了A<Ty1,Ty2>::A(const A&)（包括函数主体声明为= default），则A<Ty1,Ty2>::A(A&&)会被隐式删除，进而导致所有本可调用移动构造函数的场景均“改为”调用复制构造函数，导致不必要的复制。

C++11后，类模板内的函数声明可以且“应当”直接使用类模板名（视为一个完整的类型），默认其模板参数和类模板的参数一致，如：
1
2
3
4
5
6
7
8
9
template<class Ty>
class MyVector
{
public:
    void swap(MyVector&);  //Type of `rhs` is `MyVector<Ty>`, no need to specify
    
    template<class UTy>
    void swap(MyVector<UTy>&) = delete; //Can be explicitly specified and instaniated(as a class template)
};

同时不难发现，移动语义的实现是递归的——让一个上层“适配”类实现移动语义，若其并不直接管理资源，则只需令各非静态成员均实现其移动语义即可。

太初——Rule of Zero

If you can avoid defining default operations, do. ——C++ Core Guidelines

对于较上层的实现/适配类，尽可能避免自定义五个函数中的任意一个（令编译器自动补全完整的语义实现），即只定义（普通）构造函数用于初始化这些数据成员。
比如一个自定义字符串类的“托管”实现就可以形如：

class MyString
{
public:
    MyString() = default;
    MyString(std::string_view sv):data(std::from_range,sv){}
    //...

private:
    std::vector<char> data;
};

由于std::vector能够胜任内存管理的任务，因而不再需要为MyString这一上层适配类再自定义“五类函数”。
自定义五类函数不仅麻烦，而且容易在函数主体编写、函数类型声明等方面出现疏漏，导致不能充分利用语言工具乃至出现编译错误。

不能充分利用语言工具的实例可见C++——右值引用与移动语义

附录：

C++（乃至很多程序设计语言）的较好实践之一就是尽可能利用被无数代码不断检验测试过的、多次优化过的、实现统一且准确的标准库实现。不建议在程序设计中“手搓”资源管理、基本算法（如排序、查找等）的代码，尽可能采用既有的标准库实现——手搓费时费力~~虽然也算是一种乐趣，上述观点更多地用于大型、正经的程序/项目开发~~且极易出现各种疏漏，且其在基本算法上的效率几乎必定次于被优化检验过的标准库算法。

如C++中的std::(ranges::)sort，其就会根据待排序目标大小来动态决策采用何种排序方式：

子序列长度特别大时，会先采用堆排序(heap sort)；
子序列长度中等时，采用改良过的快速排序(quick sort)；
子序列很短时，直接采用插入排序(insert sort)。

更多有关C++设计哲学的解读参考可移步C++ Core Guidelines，其间内容致力于在基本语法要求的前提下，提供一种编写更高效、可读、易于维护与拓展代码的思路。

展开全文 >>