C++ A+B最长代码挑战：用类、模板与状态机把两行算法写成工程设计

如果你在某个技术群里收到一个 300 行的 C++ 工程，而它运行之后的功能就是读入两个整数并输出它们的和，第一反应多半是想骂人。但我知道这类代码真实存在，而且很多人写起来会越写越上头。“A+B问题最长代码”本质上就是一门技术行为艺术，把两行能写完的算法题，故意用类、继承、模板、状态机、设计模式包成一个大块头。

这个整活玩法并不是单纯的“无聊”。恰恰相反，它能帮你检验是否真正理解了 C++ 的核心机制。如果你只背过“类与对象”“虚函数”“模板元编程”这些概念，但不清楚它们在编译期和运行期到底做了什么，那这种代码你根本堆不出来。所以它很适合刚学完 C++ 基础、准备面试、或者觉得刷题没意思的人。下面我会从原理、实操和踩坑三个角度，把这种“最长代码”的玩法完整拆解，也会给出一份能编译运行的加长版参考实现，让你看完能自己动手复现甚至超越。

1. 两行的 A+B 为什么会有人故意写长

1.1 A+B 问题在程序员社区里的特殊地位

A+B 问题几乎是所有算法在线评测系统的第一道题，要求通常只有一句话：读入两个整数 a 和 b，输出它们的和。它本身没有任何难度，所以在绝大多数新人眼里，它就是一块敲门砖，用来熟悉输入输出格式。

但正因为 A+B 太简单、太标准，它反而成了一种文化符号。各大 OJ 上都有“这道题能写多短”的挑战，于是也衍生出了反方向：你能把它写多长、写多绕、写多“庞大”？这个反向挑战在 C++ 社区尤其受欢迎。原因是 C++ 语言本身特性极其丰富，支持面向对象、泛型、函数式、底层内存操作、并发以及各种抽象机制，只要你想绕，真的很能绕。

最短代码和最长代码，本质上考验的是两种完全不同的能力。写最短代码要求熟悉语法糖和语言边界，而写最长代码要求你能把日常工程中用到的架构手法全部堆上去，并且保证代码还能编译、链接、运行。后者其实更能反映你对 C++ 的真实掌握程度。

1.2 正常解法到底长什么样

先说常规的竞赛写法。大多数 A+B 题目的标准答案在 C++ 里不会超过 8 行：

cpp复制#include <iostream>

int main() {
    int a, b;
    std::cin >> a >> b;
    std::cout << a + b << std::endl;
    return 0;
}

如果再压一压，用全局变量，可以更短；如果用 C 语言配合 scanf 和 printf，还可以再少几行。但不管怎么精简，题目本体的逻辑就是一个加法表达式。

“最长代码”的目标，就是把 a + b 这个原生表达式藏起来。一个合格的长代码版本，应该做到两点：第一，代码行数和文件数足够夸张；第二，代码在逻辑上“看似合理”。如果写得太过无厘头，比如从头到尾涂满注释，那只是字符数量的胜利，没有任何技术含量。最有意思的写法是给这个两数相加的问题加上大量本不需要的“架构”，让阅读者产生一种“你好像说得很对但完全没必要”的感觉。

这也是整个项目最吸引我的地方。你必须在脑海里同时装住两套逻辑：一套是问题本身的三行算法，另一套是你为了撑篇幅而搭出来的复杂结构。结构越复杂，变量之间的生命周期、归属关系、抽象层级就越难协调，稍有不慎就会编译失败。

2. 把 A+B 写长：我常用的五类“膨胀武器”

2.1 类、继承与多态：给加法套上三层虚调用

我最先上手的方式是面向对象。把 a + b 拆成“两个数分别从哪里来”和“加法操作由谁执行”两个问题。既然要拆，就干脆拆出接口。

你可以定义三个角色：一个输入源接口，负责给程序提供数字来源；一个二元运算接口，负责描述某种计算；一个计算器类，负责把输入和运算串起来。然后在实现层各做两个具体类，比如标准输入流、文件输入流、加法实现、乘法实现等。再让计算器持有这些接口的指针或引用。

这么写的问题核心不在“类”，而在“虚函数调用链”。当程序执行 a + b 时，正常的指令只是从内存里读两个值，一个 ADD 指令就结束了。但如果你通过虚函数调用，编译器需要先查虚函数表，再做一次间接跳转，才能到达真正的加法代码。中间每个层次都增加了一次运行时开销，而且任何一层析构函数忘了写 virtual，删除基类指针时就会产生未定义行为。

同样地，代码行数会成倍增长，这是一件自然而然的事。因为每个类都要写构造函数、析构函数、成员函数以及文件之间的包含关系。如果你把每个类拆到单独的头文件和源文件中，工程里光是空壳文件就有十几个。

2.2 模板与编译期计算：让编译器在编译阶段替你加一次

如果说虚函数是把加法从运行期的几个指令伸长，那模板则是把加法搬到编译期。模板元编程写起来有一种独特的“算法感”：

cpp复制template <int Left, int Right>
struct CompileTimeAdder {
    static constexpr int value = Left + Right;
};

这段代码可以直接求出 CompileTimeAdder<2, 3>::value 等于 5。因为模板参数必须在编译期确定，所以你没办法把 std::cin 读到的变量直接传进去。如果整道题都用模板，就需要额外设计出“把运行期输入映射到编译期常量”的机制，比如用 switch case 做一堆分支映射，这就是另一个巨大的行数来源。

C++ 模板实例化机制本身也有一个额外的好处：它会让编译错误信息变得无比长。你写普通代码时，编译器报错一般是几十行，而模板元编程的报错可能刷出几百行，对排版在社区里的人而言，这本身就是一种“风景”。不过要小心，模板递归不是无限度的，后面第四章我会具体说编译器那个“深度上限”有多现实。

2.3 函数指针、回调和状态机：让执行路径绕路走

另一种有效的膨胀方式是改变“程序走到加法”的路径。

最朴素的想法是定义一个函数指针数组，把很多操作都放进去，然后用索引触发加法。再高阶一点，你可以把它做成一个状态机：先读第一个数字，进入“等第二个数字”的状态；等第二个数字到位，再进入“执行加法”状态；最后进入“输出结果”状态。这个状态机循环本身就有大量的 switch case 或 if-else，看起来工程味十足。

函数指针的回调机制也特别适合嵌进这里。比如你先注册一个回调函数，等输入类收集完两个数之后，通过回调触发加法。这样你至少要多写几个类型别名和函数赋值操作，而且 C++ 里成员函数指针与普通函数指针并不兼容，踩起来非常容易出编译错。我在第一次实践时直接把 std::cin 的读取过程写成了回调，结果发现成员函数指针的调用方式与普通函数不同，折腾了半小时才把类型声明搞对。这件事告诉我：想用函数指针写长代码，一定要先把 C++ 类型系统的几个细节弄明白。

2.4 标准库容器与算法：给数字增加大量中间存储

如果你觉得对象和状态机都太虚了，那就用容器来增加实际的数据流动。

最简单的方案是把两个数字先放进 std::vector<int>，再用 std::accumulate 求和。这个思路会把“加法”隐藏到一个综合算法里，不像裸加的 + 那么明显。你要包含 <vector> 和 <numeric>，要构造容器，要调用成员函数 push_back，最后还要理解迭代器区间。每一步都增加代码量，而且每一步在概念上都不算错。

如果还嫌不够，可以把一维数组扩展成多维数组，比如用一个 int[2][1] 存两个输入。这种写法虽然同样能跑，但你已经把一个线性逻辑硬生生改成了索引访问逻辑。

还可以上结构体链表：手动定义一个 Node，每读一个数就把它挂在链表尾部，最后遍历链表求和。这时你要额外处理内存分配和释放。如果忘记 delete 会产生内存泄漏，如果释放之后又继续使用会产生悬空指针。这些细节放到真实题目里完全没有必要，但作为训练确实会让你对指针、链表和 RAII 的理解更深。

2.5 异常处理与资源管理：把“不可能失败”的部分做成防御式

最后一种常用武器是防御式编程。A+B 按理说只要输入正确就不会发生任何异常，但你可以给整个流程铺满异常处理逻辑：

• 读取失败时抛出 std::runtime_error；
• 输入数量不足时抛出自定义异常；
• 计算结果溢出时抛出 std::overflow_error；
• 在 main 函数里捕获异常并输出日志。

为了跟踪资源，你还会引入智能指针 std::unique_ptr 或 std::shared_ptr。让不同对象共享同一个输入源时，shared_ptr 特别合适，因为多个下游类需要同时引用它。但这些智能指针一旦出现循环引用，析构又成了新问题。于是你还要考虑接口拆分成 shared_ptr 还是裸指针，这又是一大堆思考量。

把以上这五类武器排列组合，已经很轻松能堆出 500 行以上，而且每一层代码看起来都很正规。接下来我选一个更具体、更完整且能编译运行的代表性实现，给你做逐段讲解。

3. 解剖一份能跑起来的加长版 A+B 实现

3.1 设计思路：为什么每一层看起来都“有点道理”

我给的这份代码不会故意写 500 行注释来撑篇幅。我采取的策略是“企业级分层”：把输入、解析、运算、组装四个职责拆开，然后通过接口把运算过程变成抽象调用。每一个类的存在都有名义上的理由，只是对于 A+B 题目来说，这些理由全部过度设计。

代码总共只有一百多行，但它已经包含了现代 C++ 中很常见的组件：接口、继承、虚函数、智能指针、容器、异常处理。如果你想把它撑到几千行，可以再往每个类中加入模板、状态机、文件 IO、线程、宏，甚至自定义内存分配器。下面先看能直接运行的版本：

cpp复制#include <iostream>
#include <memory>
#include <string>
#include <vector>
#include <stdexcept>

// 第 0 层：被计算的值
class Value {
public:
    explicit Value(int data = 0) : data_(data) {}

    int get() const {
        return data_;
    }

private:
    int data_;
};

// 第 1 层：抽象二元运算接口
class BinaryOperation {
public:
    virtual ~BinaryOperation() = default;

    virtual Value execute(const Value& left, const Value& right) const = 0;
};

// 第 1.5 层：真正的加法实现
class AdditionOperation : public BinaryOperation {
public:
    Value execute(const Value& left, const Value& right) const override {
        return Value(left.get() + right.get());
    }
};

// 第 2 层：输入源抽象
class IInputSource {
public:
    virtual ~IInputSource() = default;

    virtual int readInt() = 0;

    virtual bool hasNext() const = 0;
};

// 第 2.5 层：从标准输入读取
class StandardInputSource : public IInputSource {
public:
    bool hasNext() const override {
        return true;
    }

    int readInt() override {
        int value = 0;
        if (!(std::cin >> value)) {
            throw std::runtime_error("StandardInputSource::readInt: input error");
        }
        return value;
    }
};

// 第 3 层：把输入解析成两个 Value
class ExpressionParser {
public:
    explicit ExpressionParser(std::shared_ptr<IInputSource> source)
        : source_(std::move(source)) {}

    std::vector<Value> parseTwoOperands() {
        std::vector<Value> operands;
        operands.reserve(2);

        for (int index = 0; index < 2; ++index) {
            if (!source_->hasNext()) {
                throw std::runtime_error("ExpressionParser: not enough operands");
            }
            operands.emplace_back(source_->readInt());
        }

        return operands;
    }

private:
    std::shared_ptr<IInputSource> source_;
};

// 第 4 层：应用门面，把各部分组装起来
class CalculatorApplication {
public:
    CalculatorApplication() {
        inputSource_ = std::make_shared<StandardInputSource>();
        parser_ = std::make_shared<ExpressionParser>(inputSource_);
        operation_ = std::make_shared<AdditionOperation>();
    }

    int run() {
        std::vector<Value> operands = parser_->parseTwoOperands();
        Value answer = operation_->execute(operands[0], operands[1]);
        return answer.get();
    }

private:
    std::shared_ptr<StandardInputSource> inputSource_;
    std::shared_ptr<ExpressionParser> parser_;
    std::shared_ptr<AdditionOperation> operation_;
};

int main() {
    try {
        CalculatorApplication application;
        int answer = application.run();
        std::cout << answer << std::endl;
        return 0;
    } catch (const std::exception& exception) {
        std::cerr << "Exception: " << exception.what() << std::endl;
        return 1;
    }
}

整个过程依然是“输入两个整数并输出和”，但 a + b 的原生 + 被藏在了 AdditionOperation::execute 里。正常阅读这段代码的人，需要先理解抽象接口、虚函数重写、智能指针所有权、容器生命周期、异常机制，才能画清它的调用链。

3.2 每一段到底在“加什么戏”

需要说明的是，这个版本并没有用到最极端的手段，它所有的类都有同一个目的：把一个本来只有一个步骤的操作，拆成若干职责。但在拆的过程中，你会立刻感受到 C++ 的若干设计原则开始打架。

比如 StandardInputSource::hasNext() 在这里直接返回 true，看起来有点无脑。但如果你真的去思考这个接口应该如何实现，就会面临一个困境：标准输入流很难在不消耗输入的情况下判断“是否还有下一个数”。若想实现真正的 peeking 行为，需要自己缓存字符流或者使用 std::cin.peek()，而 peek() 对空白字符和数字的处理会让逻辑复杂不少。这个接口在真实工程里需要认真设计，而 A+B 场景下它根本不需要存在。这种“为了合理而变得更加不合理”的感觉，正是整活代码最有意思的地方。

再如 ExpressionParser 返回的是 std::vector<Value>。正常情况下你只需要两个变量，但用 vector 的好处是支持统一遍历，坏处是它引入了堆内存的开销，并且调用方必须检查 size() >= 2 才能安全访问。如果顺手把 vector 改成二维数组或链表，能扩展的空间会更大。

main 函数里的 try-catch 也属于过度防御，可是对于一个“设计完好的企业级模块”，如果没有让异常冒泡到上层，反而显得不够专业。就这样，每一个正常的工程决策放在 A+B 问题上都显得好笑，但单看每一段，你又说不出它有什么大错。这就是“长代码”能带来阅读体验的原因。

3.3 如果想继续膨胀到上千行，有哪些正统手段

别小看这段一百多行的代码，它是一棵很适合继续长叶子的树。我会按照以下顺序扩充：

第一，把所有类拆到独立文件。.h 放声明，.cpp 放实现，再给每一个类写一个私有的拷贝构造函数或者 delete 说明。光是文件分拆和包含保护，就能多出两百行。

第二，增加构造参数和默认配置。比如让 AdditionOperation 支持“是否取绝对值再相加”这种用不上的开关，再定义对应的枚举类型和转换函数。

第三，给 Value 类增加更多数学运算符重载。你可以写 operator+、operator-、operator==、operator<<，让 Value 成为一个完整的数值包装类型，而不是只负责存 int。

第四，引入工厂。设计 OperationFactory，用字符串指定“add”时返回加法对象。这样做不仅需要更多的头文件，还要处理空指针和未匹配分支的异常。

第五，把输入解析升级为真正的 token 扫描。把字符串按空格拆成 token 列表，再挨个解析成整数，解析过程中要考虑符号、空白、多行输入等问题，这样就可以顺理成章地引入十几行状态转换。

第六，加入日志。定义日志级别，在每次操作前打印一条 INFO，在析构时打印一条 DEBUG。日志类如果做成单例，又会带来线程安全、静态初始化顺序等问题。

做完以上六步，轻轻松松 1500 行。整个过程里你其实会特别明显地感觉到：把代码写长并不难，难的是写长之后它还能被维护和阅读。一旦你真正动手试过，就会明白“短小的代码并不总是最好，但无意义的冗长绝对是灾难”。

4. 挑战“最长”之前，先了解测量指标与编译极限

4.1 三分钟统计出代码到底有多长

既然目标是“最长”，你就得有一个客观的度量标准。有人认为比行数，有人认为比字符数，还有人认为编译器生成的汇编指令条数才算数。从实际可操作性来看，最先看的是行数和字节数。在 Linux 或 macOS 终端里可以这样统计：

bash复制wc -l aplusb.cpp
wc -c aplusb.cpp

如果安装了 cloc，还能按代码行、注释行、空白行分开统计：

bash复制cloc aplusb.cpp

在 Windows 上，如果你使用 Visual Studio，可以直接看主编辑器的行计数；如果用 PowerShell，可以用 Get-Content 配合 Measure-Object -Line -Character 统计。

但行数并不等于代码“含量”。满屏写一行注释，字符数量能飙升，逻辑复杂度却不高。真要衡量挑战成果，可以考虑三个维度：代码物理行数、有效逻辑语句数、程序状态空间大小。第三个维度听起来很玄，其实就是在问：你的程序里有多少个分支？多少个类实例？多少个状态转换？像状态机方案的状态枚举一变多，状态数就会明显增加，这在代码行数上未必直观，但在控制流复杂度上非常显著。

4.2 编译器也有脾气：深度限制、头文件地狱和链接错误

很多刚开始整活的人会忽略一件事：你的代码越长，编译器的工作量越大，而 C++ 编译器并非无限宽容。

模板元编程最容易踩到的限制是模板递归深度。GCC 的默认模板实例化深度在几百到 900 之间，具体取决于版本和平台。如果你用递归模板去算 1+1 之后的“编译期计数”，递归次数超过上限时，编译器会直接报错。你可以用编译选项适当提高，例如 GCC 和 Clang 支持：

bash复制g++ -std=c++17 -ftemplate-depth=2048 aplusb.cpp -o aplusb

另外，当你把长代码拆到多个头文件和源文件时，很容易发生重复定义。类成员函数如果直接写在类定义里，它会隐式成为 inline 函数；但如果你先只声明，又在两个 .cpp 文件里分别定义同一个函数，链接器就会报 multiple definition 错误。解决方法是把非常量全局变量用 inline 修饰，或者在头文件里声明、只在某一个源文件里定义。

模板和头文件组合起来，还会让编译时间显著拉长。一个几千行的模板元编程工程，编译时间可能是普通 A+B 的上百倍。所以给自己准备的编译命令必须带着警告，便于早点发现问题：

bash复制g++ -std=c++17 -Wall -Wextra -pedantic aplusb.cpp -o aplusb

4.3 长代码和真实工程之间的那条线

我得说句大实话：这种“最长代码”适合用来学习，不适合用来提交作业，更不适合出现在生产项目里。

真实工程讲究可读性、可测试性、可维护性，代码长不长不是独立指标。有时候代码长是因为你有意拆细，让每个函数只做一件事；有时候代码短是因为你在用极高的抽象把逻辑隐藏在框架后面。但 A+B 最长代码的问题在于，它的抽象是“为了抽象而抽象”。核心逻辑只有一行，周围的包装器却层层叠叠，这种代码在 code review 时会被骂得体无完肤。

但反过来想，你能写出来，说明你对类的设计、指针的传递、编译器的限制是有概念的。只要最后能转化成正向能力，知道在哪里停下，那么这个项目就算没白玩。

5. 常见翻车现场与排坑经验

5.1 最容易翻车的五类问题

前面说长代码考验基础，那就一定有各种花式翻车方式。我自己实践时遇到最多的有五类问题，整理成速查表给你参考：

5.2 我踩过的一个经典坑：虚析构缺失导致的内存问题

有一次我写长代码时，基类叫 Operation，派生类叫 ComplexOperation。我以为自己只通过 Operation* 调用执行函数，所以析构函数可以省掉。测试时程序看似正常，但后来我在 ComplexOperation 的成员里加了一个 std::vector，再用智能指针释放对象，发现 vector 的析构没有被正确触发。

原因就是基类没有虚析构函数。C++ 里，当通过基类指针删除派生类对象时，只有析构函数被声明为 virtual，编译器才会走“先析构派生类，再析构基类”的正确路径。我那次之所以还能看到“正常现象”，是因为对象恰好没有持有必须释放的外部资源，等加上容器后问题才暴露。细节越多的长代码越容易踩这种坑，排查时别只盯逻辑，先检查类型层级设计。

5.3 另一个高频问题：模板与隐式转换一起出现，报错信息特别长

模板元编程最折磨人的还不是功能写不出来，而是编译失败时给出一屏又一屏晦涩信息。比如你定义了一个接受 std::vector<int> 的函数模板，而实际传入的是 std::vector<double>，编译器会因为类型不匹配打印大量推导记录。整活项目里如果把运算符重载和模板混在一起，报错信息甚至可以刷到几百行。

想减少这类问题，我的经验是：先写一个不用模板的非泛型版本，确认逻辑正确；再把它改成模板版本，每次只改一小块并立即编译。拒绝一次性写几百行再验证，否则出错了根本不知道是哪个模板参数导致的。

5.4 小步提交：避免长代码里“一步掉坑里”

最后送你一个非常实用的操作习惯。为这种项目用上 git 或任何版本管理工具，每完成一个可编译的小阶段就提交一次。我给自己的提交记录一般这样划分：

第一次提交只加输入输出最简版；
第二次提交把输入源包装成类；
第三次提交把加法操作独立成类；
第四次提交引入 std::shared_ptr 管理对象；
第五次提交加入异常处理；
第六次提交加模板扩展或状态机；
第七次提交再尝试写注释文档。

这样每次新建分支或回退版本都很方便，排查问题时也能清晰看出是哪一步破坏了代码。别嫌麻烦，我在没有版本管理的阶段，曾经因为一次重构把整个 200 行代码全部改崩，最后只能从头记忆重写，那种滋味真的不好受。

写在最后：这种“无聊”其实很有用

我个人在实际操作中的体会是：A+B 最长代码挑战最珍贵的地方，不是创造了一个搞笑产物，而是逼着我把 C++ 的所有底层配角都复习了一遍。为了“延长”代码，我去查了虚函数的实现机制，发现 vtable 指针会被编译器安排在对象的某个位置；为了设计类层次，我重新思考了析构函数应该什么时候加 virtual；为了让模板能跑，我还研究了编译期常量与运行期变量之间的鸿沟。

如果只是常规刷题，这些东西可能很长时间都只是“听说过”“面试前背一下”，并不会真正内化成直觉。而这个整活项目会迫使你在实践里把它们全部用起来，犯错、排查、再修正。

当然，玩归玩，别拿这种东西当求职项目去展示。如果真要给人看，你可以保留那个长版本，再在 README 里写一份“正常解法”的三行代码，让读者自己感受工程设计的边界在哪里。能在“短”和“长”之间自由切换，才是一名 C++ 开发者真正成熟的信号。