1. 模板报错为什么像天书先从最痛的地方说我写模板写了几年最不愿意面对的从来不是模板本身而是模板实例化失败时那一整屏飘红的编译错误。明明只是把一个不该传进来的类型传给了模板编译器却能头也不回地钻进标准库内部把一堆和我的代码毫无关系的内部模板展开全翻出来。C20 的 Concepts概念就是冲着这个痛点来的给模板参数加上可命名的约束条件让类型检查发生在进入函数体之前而不是等实例化炸开之后才手忙脚乱地定位。这篇文章写给两类人一类是已经会写基础模板、但还没深入接触 C20 新特性的同学另一类是天天被模板报错折磨想找个一劳永逸的约束方案顺便确认自己手上的编译器到底能不能跑 C20 的老开发。我会把 Concepts 的语法、原理、常见坑和编译器支持现状一次性讲清楚尽量不绕弯子。1.1 一个老生常谈的场景std::sort 与不合适的容器先看一个每个 C 开发者大概率都碰过的例子#include algorithm #include list #include string int main() { std::liststd::string data {hello, concepts, world}; std::sort(data.begin(), data.end()); }std::sort在旧标准里要求随机访问迭代器而std::list的迭代器是双向迭代器类型上根本不满足要求。可编译器不会直接告诉你list 的迭代器不是随机访问迭代器它只会一头扎进algorithm内部的模板实现里展开十几层模板调用最后在某个犄角旮旯报一句类似对迭代器类型执行it n操作不合法的错误。如果你是在一个大型项目里这个错误信息又会叠加好几层自定义容器的迭代器包装定位起来更痛苦。用户看到的暴露出的问题点是std::sort(data.begin(), data.end());这一行但报错的信息流却像是从标准库深处冒出来的一样这也就是所谓模板错误像天书的根源。而 C20 里新增的std::ranges::sort就完全不同——它用 concept 直接约束了随机访问范围这个要求。你传进去一个std::list编译器会在候选集阶段就告诉你不满足std::ranges::random_access_range约束不再去函数体里翻箱倒柜。1.2 enable_if、SFINAE这些老办法差在哪在 Concepts 出现之前C 也有一套约束模板参数的机制最典型的就是 SFINAE 配合enable_if。比如想限制一个函数模板只接受整数类型很多人会写template typename T std::enable_if_tstd::is_integral_vT, T double_it(T v) { return v * 2; }这段代码能工作但有三个尴尬的地方。第一可读性差。enable_if_t那一长串类型表达式读起来完全没有这个模板只接受整数的自然语言感。你真实想表达的是参数必须是整数而不是如果 T 是整数则返回 T 类型的值否则用一个空类型触发 SFINAE。第二报错并不友好。如果你传一个double进来编译器一般只会说找不到匹配的函数或者干脆列出一堆从enable_if内部展开的模板痕迹看完之后依然不知道是被哪个条件卡住了。这就是典型的候选被删除但理由被吞掉。第三重载和多种约束组合的写法极其啰嗦。多个条件用enable_if组合时常常要引入额外的模板参数、std::void_t、decltype试错等等这些技巧非常考验模板元编程功底普通业务代码里根本不想见它们。Concepts 要做的就是把这套模板参数要求从一堆类型运算中解放出来变成可以命名、可以复用、编译器也能直接拿来生成可读错误信息的一等公民。2. Concept的本质给模板参数写“岗位描述”不是发明新类型2.1 从 typename T 到 Addable很多人第一次看到concept关键字会下意识把它想成运行时接口或者抽象类其实两码事。Concept 是一个编译期谓词——你可以把它理解成一个返回布尔结果的模板函数只是它不运行在运行时而是运行在编译器的模板检查阶段。看一个最简单的概念定义#include concepts template typename T concept Addable requires (T a, T b) { { a b } - std::convertible_toT; };这段代码做了三件事声明模板参数T定义一个名为Addable的 concept然后说明它的约束条件是——a b这个表达式合法并且结果类型可以转换为T。有了这个概念之后模板参数列表里就可以直接用概念名来代替typenametemplate Addable T T add(T a, T b) { return a b; }这里Addable T的语法给人的阅读冲击是很直观的这个模板不再接纳任意类型它只接纳可以相加的类型。从语义上看AddableT相当于给T写了一份岗位描述——要能交付operator这个能力。还有两种等价写法也一并看到因为市面上代码风格混杂三种都会见到// 写法一typename requires子句 template typename T requires AddableT T add(T a, T b) { return a b; } // 写法二受约束的占位类型constrained placeholder auto auto add(Addable auto a, Addable auto b) { return a b; }写法二甚至不用写template关键字函数参数里直接写Addable auto含义是这个参数必须是满足 Addable 的类型。注意在这种写法里a和b可以是不同类型只要各自满足Addable就行。2.2 为什么它比传统写法更接近人的思维用一个生活化的类比templatetypename T就像招聘启事上只写招一个人至于这个人是会 Python 还是会 C进公司之前完全不管等实际干活实例化时才发现干不了再费劲辞退。而templateAddable T就像明确写了应聘者必须会加法运算——简历筛选阶段约束检查就把不符合的人过滤掉了剩下的进入面试函数体实例化的都是基本盘能对齐的。这带来一个很实际的好处模板的接口契约变得可见了。之前一个函数模板声明放在那里你不看函数体永远不知道它到底对类型有什么隐式要求。现在只要看参数列表里的 concept 名就能八九不离十地判断出它能接受什么类型、不能接受什么类型代码本身就是文档。另外强调一个很多初学者容易误会的点concept 不是在运行时给类型做检查的机制它没有任何运行时开销也没有虚拟表。它只在编译期被求值成一个布尔常量满足就继续编译不满足就报约束错误。你可以把它理解成一套更完善、更可读、报错更友好的编译期 if。3. requires 子句与 requires 表达式两套容易混的语法一次讲透3.1 先分清两个“requires”的身份进入实战之后最容易绕晕的就是requires在两种不同语境下完全不同的身份。第一种是requires 子句requires-clause它出现在模板参数列表之后用来给整个模板加约束条件。例如template typename T requires AddableT void foo(T x) {}这里的requires AddableT是模板声明的一部分意思是只有满足AddableT时这个模板才参与重载决议。第二种是requires 表达式requires-expression它可以出现在任何编译期需要布尔结果的地方最常见的用途是放在 concept 定义体内部用来声明对类型的具体要求template typename T concept Addable requires (T a, T b) { { a b } - std::convertible_toT; };这里的requires (T a, T b) { ... }是一个表达式它本身会求值为true或false。花括号里的a、b只是声明给后续检查用的占位变量编译器不会真的创建这些变量也不会真的有运行时对象。它只是用这些名字去检验如果把a b这个表达式放在当前上下文里它成不成立。区分这两者的一个口诀requires 后面如果带模板参数列表或紧跟约束条件多半是子句requires 后面如果跟的是带参数列表和花括号块的代码那是表达式。3.2 四种要求简单、类型、复合、嵌套在 requires 表达式内部一共有四种要求写法很多教程把它们揉在一起讲导致初学者看概念定义时觉得像天书。我用一张表拆开来看。类型写法含义与示例简单要求expr;表达式必须合法。例如t.size();要求对象能调用size()类型要求typename T::xxx;嵌套类型必须存在。例如typename T::value_type;要求内部有value_type复合要求{ expr } - Concept;表达式合法且结果类型满足某个 concept。例如{ a b } - std::convertible_toT;嵌套要求requires ConceptT;必须满足其他概念。例如requires std::destructibleT;写一个同时包含四种要求的例子#include concepts template typename T concept EmptyContainer requires (const T t) { t.empty(); // 简单要求能调用 empty() typename T::value_type; // 类型要求内部有 value_type requires std::destructibleT; // 嵌套要求可析构 };这段概念表达了一个很自然的需求这是一个空容器概念——能检查为空、有元素类型、并且可正常析构。注意类型要求里的typename关键字不能省略。typename T::value_type明确告诉编译器这里我们说的是类型而不是静态成员变量或成员函数。如果漏掉typename在模板语境里很有可能被误解析为表达式。3.3 复合要求的返回值约束一个必须用 concept 的细节复合要求的-后面到底能写什么是新手翻车率最高的语法细节之一。C 标准规定复合要求的返回约束必须是类型约束type-constraint简单来说就是 must be a concept。很多刚接触的人会尝试直接写一个具体类型template typename T concept Bad requires (T t) { { t 1 } - int; // 错误 };这在 GCC 和 Clang 上是编译不过的标准明确要求这个位置必须是 concept。你想表达返回类型是 int正确写法是用std::same_as概念来约束template typename T concept Good requires (T t) { { t 1 } - std::same_asint; };如果你想表达的是返回值可以隐式转换为 int则用std::convertible_totemplate typename T concept Good2 requires (T t) { { t 1 } - std::convertible_toint; };这两个概念看起来相似语义差别却很大same_as要求类型完全一致convertible_to只要存在隐式转换即可。写代码时先想清楚你到底需要哪种否则容易被隐式转换坑到。这是我在实际项目中踩过的一个非常典型的坑专门写出来提醒一句。4. 标准库concepts初体验先做“抄作业”选手4.1 头文件里的常用concepts清单写自己的 concept 之前先了解标准库已经送了什么。concepts头文件里定义了大量即拿即用的常用概念我按场景列几个高频的。概念含义std::integralTT 是整数类型包括char、int、long等std::floating_pointTT 是浮点类型std::signed_integralT/std::unsigned_integralT有符号/无符号整型std::same_asT, UT 和 U 是同一个类型std::convertible_toT, UT 可以隐式转换为 Ustd::destructibleT类型可以正常析构std::constructible_fromT, Args...类型可以用给定参数构造std::movableT类型可移动构造、移动赋值std::copyableT类型可拷贝std::semiregularT可默认构造 可拷贝/移动 可析构std::regularTsemiregular 支持相等比较行为像普通值类型std::equality_comparableT支持和!std::totally_orderedT支持、、、且符合全序关系std::invocableF, Args...F 可以用 Args... 调用std::predicateF, Args...F 可以用 Args... 调用且返回类型可转为 bool另外std::ranges::rangeT、std::ranges::random_access_rangeT这一类定义在ranges头文件里专门用来描述范围类型。4.2 用标准concepts写求最大公约数和限制类模板标准库 concepts 最大的使用价值是让你在很多场景下不需要亲自写 requires 表达式。比如我只想写一个只接受整数类型的函数模板#include concepts template std::integral T T gcd(T a, T b) { while (b ! T{0}) { T r a % b; a b; b r; } return a; }template std::integral T直接约束了模板参数必须是整数%运算对整型都是安全的。如果你传一个double进来编译器会直接报约束不满足而不是等你跑进函数体里遇到%对浮点数非法时报错。这函数还配套了一个很有用的排错技巧用static_assert在编译期快速验证 concept 的求值结果。static_assert(std::integralint); static_assert(!std::integraldouble); static_assert(std::floating_pointdouble);写static_assert来测概念是我个人的习惯。你不需要编译整个程序只要编译这一段就能确认自己对这些 concept 的理解对不对。尤其是当你想验证某个自定义类型到底满足哪些约束时这个招数能帮你节约大量试错时间。4.3 用std::regular约束“查重容器”类模板其实 concepts 最大的便利还不止约束函数模板用来约束类模板时效果更好。之前写一个值集合类可能要写一堆static_assert放在构造函数里或者用 C17 的static_assert(std::is_copy_constructible_vT)逐个判断。现在可以直接在模板参数上声明#include concepts #include vector #include algorithm template std::regular T class ValueSet { public: void add(T value) { values_.push_back(std::move(value)); } bool contains(const T value) const { return std::find(values_.begin(), values_.end(), value) ! values_.end(); } private: std::vectorT values_; };这个std::regular的概念挺妙的——它表示的类型既支持拷贝/移动、默认构造、可析构还支持比较。一个容器想要支持std::find基于值的查重至少得能比较相等所以这里用std::regular做约束语义上非常贴切。对比 C17 时代你可能得在一堆enable_if或者static_assert里维护长串的!std::is_array_vT std::is_copy_constructible_vT std::is_destructible_vT ...而现在整个契约都浓缩在std::regular这个名字里人一看就懂编译器也看得懂。5. 同一段错误加不加concepts报错画风差距有多大5.1 无约束版本错误指向函数体内部调用处毫无线索写代码时最糟心的不是出错而是出错的信息完全不带方向感。我来实测对比一下。先定义一个没有 concept 约束的版本struct Point { int x, y; }; template typename T T my_max(T a, T b) { return a b ? b : a; } int main() { Point p{1, 2}, q{3, 4}; my_max(p, q); }在 GCC 12.2 上的报错会直接指向my_max函数体里的a berror: no match for operator (operand types are Point and Point)这个错误信息本身并不长但它有一个关键问题——它指向的是模板内部而不是调用处my_max(p, q)这一行。如果这段模板来自标准库或者来自某个很深层的依赖库那么这个operator没有匹配的错误就要叠加好几层模板调用关系变成一长串让你看不到哪里错了的报错瀑布。5.2 有约束版本编译器直接指出“约束不满足”给同样逻辑的函数加上概念约束template typename T requires std::totally_orderedT T my_max_checked(T a, T b) { return a b ? b : a; } int main() { Point p{1, 2}, q{3, 4}; my_max_checked(p, q); }这次的报错就完全不一样了GCC 12.2 实测error: no matching function for call to my_max_checked(Point, Point) note: candidate: templateclass T requires std::totally_orderedT T my_max_checked(T, T) note: constraints not satisfied note: std::totally_orderedT evaluated with T Point note: no operand types available for operator关键差别在哪报错的第一行就直接点明了调用点然后说约束没满足后面还贴心地给出了 concept 求值时失败的具体原因——找不到operator。你不需要钻进函数体内部也不需要追踪多层模板展开编译器直接告诉你根因。这就是 concepts 带来的核心体验提升错误定位从函数体深处提前到了模板候选失败点原因描述从某个表达式在那里不合法变成了约束不满足具体是哪个要求不满足。5.3 谁在背后让报错变“聪明”了为什么加了个 concept 约束报错差距能有这么大原因在于约束检查的时机。没有 concept 时my_max(p, q)发生模板实例化编译器会老老实实地把函数体里的a b也用Point去实例化此时才发现没有operator。这就像是一家公司先把你招进去、安排到工位上干了一天活才发现你根本不会用 Excel——所有问题都要等到实际干活才干到一半才暴露。而有 concept 时模板在替换参数、进入函数体之前会先做一次资格预审。编译器推导出T Point后先检查std::totally_orderedPoint是否满足不满足就直接把该模板从候选集合里划掉并记录下被划掉的原因。整个过程发生在函数体实例化之前所以报错信息自然就集中在调用点附近。这也解释了为什么很多人觉得 C20 的 concepts 让模板从玄学编程变成了工程编程——不是代码能力瞬间变强了而是编译器终于知道怎么把失败原因讲清楚了。6. 写代码之前先确认你的编译器真的支持C206.1 各编译器对Concepts的支持起步线Concepts 的标准语法在 C20 里敲定但各家编译器的落地节奏差别不小。我给一个大概的支持时间线作为参考。编译器支持 Concepts 的起始版本启用编译选项GCCGCC 10GCC 9 仅支持实验性-fconcepts-stdc20或-stdc2aClangClang 10 起基本可用需要配套标准库-stdc20或-stdc2aMSVCVS2019 16.10 起比较完整/std:c20如果在 Windows 上还守着 Visual Studio 2017那就别想了老老实实升级开发环境吧。如果用的是 Linux 发行版自带的 GCC先确认版本是否到 10。可以用g --version或clang --version查看第一行输出版本数字。6.2 小熊猫Dev-C这类工具到底行不行网上搜小熊猫 Dev-C 支持 C20 吗这类问题的朋友非常多这里我直接说结论这类 IDE 支不支持 C20基本不取决于 IDE 的皮肤而取决于它内置的 GCC 版本和编译命令参数。Dev-C、小熊猫 Dev-C、以及其他各种 Dev-C 变体本质上都是把 MinGW-w64 的 GCC 编译器包装在一个图形界面里。你打开 IDE 时看到的界面再新底层调用的还是g。所以判断标准只有两条第一内置 GCC 大版本是否 10。老版本的 Dev-C比如常见的 5.11自带的 GCC 是 4.9.2那个版本别说 C20C17 都是残缺的Concepts 完全不可能编译通过。新版的小熊猫 Dev-C 如果跟随了较新的 MinGW-w64 工具链内置 GCC 一般会到 10 甚至 11/12那就能用。第二编译参数里有没有-stdc20。就算编译器是 GCC 12如果 IDE 默认编译参数不带 C20 标准编译器依然不会启用 Concepts。一般可以在 IDE 的编译器选项或项目属性里找到类似编译标准的选项手动改成 C20。如果对当前 IDE 的 GCC 版本没底最好的办法是直接在 IDE 的终端或者命令行执行g --version版本号和 g 都看得清清楚楚比到处搜教程靠谱得多。6.3 一个最小编译验证用例我在这里提供一个最简验证程序用它能快速判断当前环境到底能不能编译 Concepts 代码#include concepts #include iostream template std::integral T T next_value(T v) { return v 1; } int main() { std::cout next_value(41) \n; }编译方式命令行环境g -stdc20 -o test test.cpp如果代码正常编译并输出42说明环境 OK。如果看到 concepts not supported 或者语法解析错误十有八九是编译器版本太低或者没启用 C20 标准。如果#include concepts都找不到头文件那基本可以确定是 GCC 版本不够新必须升级工具链。这算是我在排查IDE 支不支持概念时最常用的一招不要凭感觉先跑一个最小用例5 分钟就能确认。在 IDE 里还要多说一句部分 Dev-C 类软件的默认标准还是 C17即使代码写对了也编译不过。在菜单里找到工具 - 编译器选项或者在项目属性里的语言标准/编译标准下拉菜单中手动改成C20/GNU20再跑一次测试程序。这个动作经常被忽略但恰恰是能不能用的关键。最后再分享一点个人体会。我大概是从 GCC 10 刚开始引入 concepts 时就在项目里试用一路踩过来最大的教训是不要一上来就追求定义一个万能概念把一堆要求塞进一个 concept 里。拆成Addable、Comparable、HasSize这样的小概念再用或者嵌套要求组合报错时定位会轻松很多。原因也很简单——概念越小编译器在报错时给出的约束不满足原因就越具体、越接近你真正想表达的语义。先把标准库给你的 concepts 用熟再开始写自己的概念这个顺序我认为是最平滑的入门路径。