简介面向算法竞赛爱好者的C题库代码仓库集中存放ACMer在多平台提交通过的AC代码覆盖动态规划、图论、搜索、数学、数据结构等高频题型适配ACWing、Contest Hunter、CodeForces等OJ从基础到进阶均可找到参考。压缩包共916个文件以577个cc和289个cpp的C源码为主另有少量Kotlin、Python、Java文件辅助实现以及md笔记、脚本和图片整体仅1.03MB命名统一规范便于按平台或专题检索。仓库附有参与者的算法笔记与经典模板代码可对照学习动态规划递推、图论建图、搜索剪枝等核心思路中文注释也降低了阅读门槛同时鼓励提交自己的解法形成集体维护的代码库。已有85人学习体量小巧适合备战ACM/ICPC、蓝桥杯等竞赛的C学习者日常刷题与赛前速查。1. C算法竞赛学习仓库一份能直接抄、也能照着练的源码体系刷算法题时最难受的状态不是题目不会而是“想过但写不快”——排序、二分、最短路这些板子每次都要现场敲一遍敲完发现忘了加ios::sync_with_stdio(false)或者把写成了。如果你在 OJ 上卡过这种低级失误大概率会需要一个 C算法竞赛学习仓库它把高频考点对应的源码、模板和训练笔记放在一起让你从“看到题想思路”直接跳到“调板子改参数”。它不是什么神秘项目本质就是一份组织良好的代码仓常见形态是“源码笔记”混排方便对照着学。适合两类人刚入门的需要一个完整且能跑的参考实现有经验的赛前临时翻板子、查边界条件。这篇笔记我按自己的使用习惯把目录结构、编译运行、模板改造和踩坑路径一次讲透。2. 仓库里到底装了什么先读懂目录结构再谈抄代码下载解压后第一件事不是找main.cpp双击编译而是先花十分钟看目录。竞赛学习仓库的目录组织方式直接决定了你后续能不能快速定位到想要的模板。2.1 顶层目录与文件模板、笔记、工具脚本三件套我见过的大多数 C 算法竞赛仓库顶层一般会分成三块模板源码目录、题解笔记、工具脚本。对应到文件上往往是src或code目录、notes或docs目录以及一两个makefile或gen_data.sh。具体名称不统一但职责基本一致。目录/文件常见内容使用场景src/或code/按专题拆分的.cpp或.h文件抄模板、改参数、跑通示例notes/或docs/算法思路、复杂度分析、易错点记录读题解、复习考点、对照代码makefile/CMakeLists.txt批量编译配置一次编译多个源文件gen_data.sh/random.cpp随机数据生成器对拍、压力测试、验证边界这里有个容易踩的认知坑很多人只看.cpp文件把笔记当摆设。实际上竞赛学习仓库的笔记往往记录了当初为什么这样写、以及换一道题要改哪里比代码本身更有价值。我习惯的阅读顺序是“先看笔记里的思路再看源码最后自己重写一遍”如果只抄源码不读笔记换一道题大概率还是不会改。2.2 源码目录按专题分层数据结构、图论、动态规划不是随便分竞赛仓库的 src 目录通常按算法专题划分而不是按题号划分。常见分层data_structure/线段树、树状数组、并查集、平衡树graph/最短路、最小生成树、拓扑排序、网络流dp/背包、区间 DP、状压 DP、数位 DPstring/KMP、AC 自动机、后缀数组math/数论、组合数学、矩阵快速幂basic/排序、二分、前缀和、差分这种组织方式背后的逻辑是让你按“考点”检索源码而不是按“做过哪道题”检索。比如你遇到一道“区间最大值 单点修改”的题目直接去data_structure/下找“线段树模板.cpp”而不是去回忆以前哪道题用到了线段树。这个习惯能明显加快打板子的速度。如果你手里的仓库不是按专题分的我建议你花半小时自己重新归类——这一步会让仓库的使用效率翻倍。2.3 源码和笔记怎么配合先跑通再对照最后默写仓库里代码和笔记的配合方式通常有三种形态注释写在代码里、题解写在 notes 里、以及“代码 题目链接”放一起。我个人最推荐的是前两种结合模板代码里的注释写“这行在做什么”notes 里写“为什么这么做、复杂度多少、什么场景会卡常数”。比如一份 KMP 模板代码里会注释next[i]的意义notes 里会解释失配时怎么跳以及何时必须用 Z 算法代替 KMP。一个很实用的训练路径把仓库里basic/下的排序、二分、前缀和先跑通然后不打开源码直接在 OJ 上找 3-5 道对应专题的题照着笔记里的思路手写。写不出来再看源码看完再合上重写。这个“跑通-对照-默写”的循环是让仓库从“别人的源码”变成“你的能力”的关键。至于 C基础入门教程里那些语法细节仓库存的是“用得到的部分”语法层面不懂的还是要回补。3. 用 VSCode 与 g 把它跑起来编译参数和最小运行配置源码看懂了下一步是让它在你机器上跑起来。很多仓库没有给一键运行脚本你得自己配置编译环境。这一章我用 VSCode g 讲一套可复现的最小配置顺带回答“为什么用 g 而不是 Dev C 或在线 IDE”。3.1 环境准备确认 g 版本与 C 标准竞赛代码通常依赖 C17 特性比如结构化绑定、std::gcd、string_view。如果你的 g 版本太老编译时就会报 “未声明” 之类的错误。先跑一下命令确认版本g --version g -stdc17 --version第一条命令如果输出类似g (GCC) 11.2.0的版本号说明编译器已安装。第二条命令配合-stdc17检查是否支持 C17 标准。如果你看到command not found说明没装编译器需要下载 MinGW-w64 或 MSYS2。版本低于 9.0 的 g 对 C17 支持不完整建议升级。这里说明一下为什么强调标准竞赛题解源码里常出现auto [x, y] ...这样的结构化绑定这是 C17 才有的语法。如果不加-stdc17g 默认用 gnu14代码大概率编不过。这是新手最常见的第一个报错不是代码写错了而是编译器标准没选对。3.2 最小编译命令单文件模板直接跑确认编译器没问题后找一个模板源文件比如basic/bubble_sort.cpp用最小命令编译cd src/basic g -stdc17 -O2 -o bubble_sort bubble_sort.cpp ./bubble_sort-stdc17指定语言标准竞赛代码一律用这个。-O2开启二级优化。竞赛题比的不是编译速度是运行速度-O2能显著提升排序、循环这类代码的性能。-o bubble_sort指定输出文件名。不加这个参数默认生成a.outWindows 下是a.exe后面维护多个模板会很乱。./bubble_sort运行编译产物。Linux/macOS 下带./Windows 下直接写bubble_sort.exe。如果你的代码里同时引用了自定义头文件比如#include mylib/segment_tree.h编译命令要加-I指定头文件路径g -stdc17 -O2 -I../include -o seg_tree seg_tree.cpp-I后面跟的是头文件所在目录让编译器在默认搜索路径之外多找一层。竞赛仓库里的模板之间经常互相依赖这个参数几乎必用。3.3 VSCode 任务配置一键编译不切终端命令行编译没问题后再把它固化到 VSCode 里省得每次手动敲。在.vscode/tasks.json里写一个编译任务{ version: 2.0.0, tasks: [ { label: g build active file, type: cppbuild, command: g, args: [ -stdc17, -O2, -g, -o, ${fileDirname}/${fileBasenameNoExtension}, ${file} ], group: build, problemMatcher: [$gcc] } ] }这段配置的含义是对当前打开的.cpp文件用g以 C17 标准编译开启-O2优化并保留-g调试信息输出文件放在源文件同目录下文件名与源文件同名不带.cpp后缀。${file}是 VSCode 的变量表示当前打开文件的绝对路径${fileBasenameNoExtension}表示不带扩展名的文件名。配置完成后按CtrlShiftBVSCode 会直接编译当前文件报错信息会以列表形式列在“问题”面板里双击就能跳到出错行。这是我在本地折腾 VSCode 配置 C/C 环境时觉得最值的一步。注意-g参数必须加否则后续用 GDB 调试时看不到变量值只能看到汇编级别的跳转。3.4 为什么不推荐 Dev C 跑大型模板很多入门教程会推荐 Dev C它的优势是安装快、自带编译器适合单文件教学。但竞赛仓库里有大量跨文件代码Dev C 的工程管理和标准支持比较旧遇到 C17 代码会出现莫名其妙的报错。我的习惯是Dev C 只用来看别人代码自己开发和编译一律 VSCode g。特别是当仓库里出现filesystem、variant这类 C17 标准库组件时老版本 Dev C 基本上编译不过VSCode 的任务配置反而不用改就能跑。4. 读懂源码里的模板从冒泡排序到参数化的三种改造手法仓库里给你的是“一份能跑的源码”但要应对不同题目往往需要改参数、换类型、去掉全局变量。这一章用排序专题里的冒泡排序讲清楚怎么从“抄代码”变成“改代码”。4.1 先抄一段能跑的竞赛仓库里的排序模板长什么样打开仓库basic/下的排序模板大概率会看到一个类下面这样的实现#include bits/stdc.h using namespace std; void bubble_sort(int arr[], int n) { for (int i 0; i n - 1; i) { bool swapped false; for (int j 0; j n - i - 1; j) { if (arr[j] arr[j 1]) { swap(arr[j], arr[j 1]); swapped true; } } if (!swapped) break; } } int main() { int n; cin n; int arr[n]; for (int i 0; i n; i) cin arr[i]; bubble_sort(arr, n); for (int i 0; i n; i) cout arr[i] ; return 0; }这段代码里有三个细节值得注意。第一#include bits/stdc.h是竞赛最常用的万能头文件把 C 标准库全部引入节省写头文件的时间但会拖慢编译速度正式工程里不要这么干。第二int arr[n]是变长数组这是 GCC 的扩展语法不是标准 C严格模式下会警告但竞赛环境普遍支持。第三swapped标志位做“如果没发生交换就提前退出”的优化这是冒泡排序在有序列上保持 O(n) 复杂度的关键。4.2 把“题目版”改造成“模板版”去掉全局变量与硬编码类型仓库里的代码往往是配合某道题写的里面会混入跟题目强相关的变量。比如上面这段main里直接调用bubble_sort(arr, n)如果第二道题要排序vectorlong long这段代码就得大改。我一般会在仓库模板的基础上做三件事把数组参数改成vector引用、把比较逻辑抽成函数模板、把 IO 从cin/cout换成scanf/printf或加同步关闭。#include bits/stdc.h using namespace std; template typename T, typename Compare void bubble_sort(vectorT arr, Compare cmp) { int n (int)arr.size(); for (int i 0; i n - 1; i) { bool swapped false; for (int j 0; j n - i - 1; j) { if (cmp(arr[j 1], arr[j])) { swap(arr[j], arr[j 1]); swapped true; } } if (!swapped) break; } } int main() { ios::sync_with_stdio(false); cin.tie(nullptr); int n; cin n; vectorlong long arr(n); for (int i 0; i n; i) cin arr[i]; bubble_sort(arr, lesslong long()); for (int i 0; i n; i) cout arr[i] ; return 0; }改动点对应三种改造手法。第一种函数模板template typename T, typename CompareT决定支持int、long long、double甚至自定义结构体Compare作为比较器传入lesslong long()是升序greaterlong long()是降序改排序方向不用改函数体。第二种形参改成vectorT引用传递避免拷贝arr.size()获取长度解决变长数组不可返回的问题。第三种ios::sync_with_stdio(false); cin.tie(nullptr);关闭 C 和 C 的 IO 同步让cin/cout的速度接近scanf/printf这是算法竞赛常用技巧但代价是不再能混用cin和scanf。4.3 用测试用例验证改造正确性优先于花哨改造完必须验证不能编译过了就觉得“应该没问题”。我的做法是构造三类测试数据升序序列、降序序列、含重复元素的序列然后在本地跑一遍。// 测试模板化冒泡排序 void test_bubble_sort() { vectorint a {3, 1, 4, 1, 5, 9, 2, 6, 5}; bubble_sort(a, lessint()); assert(is_sorted(a.begin(), a.end())); vectorlong long b {1000000000LL, -1000000000LL, 0}; bubble_sort(b, greaterlong long()); // b 应降序 for (int i 0; i 3; i) cout b[i] ; }跑通后再把同样的思路迁移到仓库里quick_sort、merge_sort模板上。你会发现在读其他源码时脑子里会自动带上“这段是处理边界的”“这段是交换核心逻辑”的标签读代码的速度明显变快。这个过程就是把仓库的 C算法竞赛常用方法内化成自己的过程。5. 常见问题与避坑指南样例过了却 WA/TLE先查这四个地方有了能跑的模板真正的战场在 OJ 上。很多人在本地跑样例全对一提交就是 WA 或 TLE这种事情看起来像玄学实际上绝大多数都能从下面这四个地方找到原因。5.1 输入输出同步cin/cout 慢到超时的根因现象代码逻辑完全正确本地数据 0.1 秒跑完提交 OJ 却 Time Limit Exceeded尤其数据量在 10 万以上时。原因cin和cout默认要跟 C 的scanf/printf同步保证混用时的输出顺序正确这个同步过程极其耗时。仓库模板里如果没写ios::sync_with_stdio(false)代码在大数据下就是慢。解决在main开头固定写两行ios::sync_with_stdio(false); cin.tie(nullptr);第一行关闭与 stdio 的同步第二行解除cin与cout的绑定否则每次输出都会刷新一次缓冲区。注意这两行一旦写上就不能再混用scanf/printf和cin/cout否则结果可能错乱。5.2 整数溢出int 不够用long long 也不是万能现象求和、乘法、求组合数的题目逻辑和样例都能过数据一大就 Wrong Answer而且错得莫名其妙不是超时。原因int最大约 21 亿如果题目给的数据范围是1e9两个数相加或相乘就会溢出成负数或者变成错误的小数。很多仓库模板里初始写的是int因为出题人给的样例太小看不出来。解决读题时先看数据范围只要单个数超过2e9或者需要相乘立即把所有涉及该数据的变量改成long long。更高阶的做法是用__int128处理中间结果但竞赛头文件里要确认编译器支持__int128 a, b; // 处理超大数中间结果GCC 支持__int128但注意它不能直接cin/cout输入输出要手写字符串转换。这种技巧适合仓库里那些“大数据模板”的改造场景。5.3 递归爆栈和死循环DFS 边界条件翻车实录现象写 DFS 或递归模板时样例通过提交后 Runtime Error或者程序卡住不退出。原因竞赛仓库里的 DFS 模板常常默认递归层数够用但题目数据一大会触发栈溢出。更隐蔽的问题是递归函数里缺少“出口条件”导致死循环把栈打爆。解决加深搜之前先在纸上画清楚三个问题递归函数什么时候返回什么条件入下一层数据大了层数会不会超过系统栈限制如果深度可能超过 10 万就要改成显式栈迭代法。另外在调试阶段我习惯加一个调试计数器int depth 0; void dfs(int u) { if (depth 1000000) { cout stack overflow; exit(0); } // 原有逻辑 }这个临时调试代码是仓库里不会有的但排查递归爆栈时极其救命。把循环次数上限输出出来你能立刻知道是“没出口”还是“单纯太深”。5.4 只抄模板不改类型vector 边界与空容器判断现象从仓库抄了线段树或图论的模板数据量一大就段错误Segmentation fault。原因竞赛模板里为了性能经常用裸数组int tree[N * 4]改成vector后忘了扩容或没检查越界。另一个常见错误是取vector最后一个元素时用了arr[n]而不是arr.back()当容器为空时直接访问越界。解决凡是使用容器一律用.size()判断后再访问特别是模板代码里出现n - 1这种索引时先确认n 0。如果vector空间不确定提前用resize或者reserve避免频繁扩容。血泪经验是数据量大以后访问越界不一定会立刻崩而是随机破坏内存导致错到完全没法定位所以在本地就要开-fsanitizeaddress编译排查一次g -stdc17 -fsanitizeaddress -o test test.cpp地址消毒器会在越界访问发生时立刻打印错误位置比肉眼查代码高效一个量级。仓库模板通常没开这个编译选项你在本地排查时要自己加上。6. 让仓库变成你自己的对拍脚本、随机数据和专题重刷源码模板用顺手之后最后一步是让这套仓库为你产出自定义价值。这里分享两个我一直在用的技巧一个是随机数据对拍一个是专题重刷法。先说对拍。所谓对拍就是让“你写的代码”和“暴力解法”跑同一组输入对比输出是否有差异。仓库里的模板通常是高效实现但复杂模板的边界条件未必好调试。我习惯在tools/下放两个文件一个brute.cpp写的是最朴素的暴力解法另一个gen.cpp生成随机数据。// gen.cpp 生成随机测试数据 #include bits/stdc.h using namespace std; int main(int argc, char* argv[]) { srand(atoi(argv[1])); // 用外部传入的种子 int n rand() % 10 1; cout n \n; for (int i 0; i n; i) { cout rand() % 100 ; } return 0; }# Linux/macOS 下循环对拍 for i in $(seq 1 10000); do ./gen $i input.txt ./solution input.txt out1.txt ./brute input.txt out2.txt if ! diff out1.txt out2.txt /dev/null; then echo WA on seed $i cat input.txt break fi donesrand(atoi(argv[1]))让每次运行的随机序列可复现一旦对拍失败用同一个种子再跑一次能稳定重现。rand() % 10 1控制数据范围先跑小数据方便人眼检查错误确认无误后把范围放大到1e5顺便测性能。对拍脚本的灵魂是diff环节两边输出不一致就立刻打印输入数据直接把 Bug 暴露在最小数据集上。再说专题重刷。仓库里每个专题的模板光读一遍是不够的。我的习惯是每天选一个专题打开对应目录把 3 到 5 个模板在本地编译运行再拿模板去 OJ 上找“纯模板题”练手。比如看完并查集模板就找两道“连通性判断”“最小生成树”题要求自己不打开源码手写。写错就去看模板看两遍再合上继续写。这样循环几轮模板的边界条件父节点初始化、路径压缩、按秩合并才真正刻进操作记忆里。算法竞赛常用技巧和其他方向一样建立在“熟练”而非“听过”之上。仓库里的源码是别人的解法你只有通过改造、验证、对拍、重刷把它变成自己随手能写的代码这份 zip 才算真正拆开。对我来说最值得的投入不是把模板背下来而是把每个模板的“为什么这样写”记进自己的笔记里——下次比赛前翻自己的笔记比翻任何别人整理的仓库都有用。希望这些操作和踩坑记录能帮你在自己的学习路径上少走几趟弯路。本文还有配套的精品资源点击获取
