C++ 入门：从源代码到可验证的小程序

打开代码编辑器，输入几行 C++，再点击“运行”。这个过程看起来只有两步，中间其实发生了一串转换：文本形式的源代码被检查、翻译、组合，最后变成操作系统可以启动的程序。

很多入门问题不是算法问题，而是没有分清这条链路。例如，一段代码可以通过编译，却可能无法链接；一个程序可以正常启动，结果却可能不对。“能运行”和“做对了”不是同一件事。

这篇内容将完成一条完整的入门路径：理解程序是什么，读懂最小 C++ 程序，用 C++17 工具链构建它，通过标准输入输出做一个小应用，再用可重复的测试判断结果。

程序是可执行的精确说明

假设你告诉朋友：“到楼上左边的房间等我。”对方会自动补全大量细节：先离开座位，避开障碍物，找到楼梯，走到上一层，再判断哪边是左边。这句话不够精确，但人有常识，通常仍能完成任务。

计算机不会这样补全意图。它只会执行已明确表达、符合语言规则的操作。程序就是这类操作的精确描述；编程则包括编写、检查、运行和测试这些描述。

一个程序有两类读者

代码首先要让工具能准确处理。拼写、大小写、引号和分号都会改变工具对代码的理解。一个人可能知道 Cout 是想写 cout，编译器却只能把它们当成两个不同的名字。

代码也要让人能读懂。今天写下的程序，下周可能需要修改；一个团队中，维护它的人也往往不是最初的编写者。清楚的结构、稳定的格式和有意义的名字，能让错误更容易被发现。

从需求到结果是一个循环

写程序不是把需求一次性“翻译”成代码。更实用的做法是循环前进：

这个循环产生了快速反馈。变更越小，新问题的成因越容易确定。

小节测试

读懂最小 C++ 程序

一个可以通过编译和链接的最小 C++ 程序可以只有一行：

int main() {}

它有程序入口，但没有可见输出。为了确认整条工具链确实工作，更适合从一个能在终端留下结果的版本开始。将下面的代码保存为 hello.cpp：

#include <iostream>
 
int main() {
    std::cout << "Hello, C++!" << '\n';
    return 0;
}

运行后的标准输出是：

Hello, C++!

#include <iostream> 提供输入输出声明

#include 是预处理指令。<iostream> 是标准库头文件，其中提供了标准输入输出工具的声明。这个程序使用了 std::cout，因此要包含 <iostream>。

头文件不是装饰。如果删掉包含行，编译器在看到 std::cout 时就没有必要的声明，通常会报告名字未定义或相关错误。

main 是程序入口

int main() 定义了名为 main 的函数。操作系统启动这个可执行程序后，C++ 的执行从 main 开始。

这行可以先拆成四个部分识别：

这里只需记住整体骨架。函数、参数和返回类型的更多规则可以等真正需要自定义函数时再展开。

std::cout 把字符送到标准输出

std::cout 是标准输出流。std:: 说明 cout 来自标准库的命名空间，<< 把右边的内容依次送入输出流。

std::cout << "Hello, C++!" << '\n';

"Hello, C++!" 是字符串字面量，所以使用双引号。'\n' 是一个换行字符，所以使用单引号。语句末尾的分号用来结束这条语句。

return 0 报告成功

return 0; 结束 main，并把整数 0 交给启动程序的环境。按通常约定，0 表示成功，非零值表示某种失败。

在 main 的末尾，C++ 允许省略显式的 return 0;。入门示例保留它，是为了明确表达程序在哪里结束，以及它如何报告结果。

注释说明代码难以直接表达的意图

// 后的内容是单行注释，编译器不会把它当成要执行的语句。

// 向终端写入一条环境检查信息。
std::cout << "Environment ready" << '\n';

注释适合解释目的、限制或看不出来的决策。像 // 输出 Hello 这样重述代码的注释帮助不大。修改代码后，还要确认相关注释仍然准确。

小节测试

从源文件到可执行文件

hello.cpp 是源文件。它是人可以阅读和修改的文本，却不是处理器直接执行的机器指令。C++ 使用编译型工作流，通常要经过下面几个阶段：

hello.cpp
   │  预处理与编译
   ▼
目标代码（hello.o 或 hello.obj）
   │  与标准库等代码链接
   ▼
可执行文件（hello 或 hello.exe）
   │  由操作系统启动
   ▼
运行结果与退出状态

实际工具可能还会经过更细的内部阶段。入门排错时，最有用的边界是“编译”和“链接”：前者主要检查和翻译单个源文件，后者负责把程序的各个部分组成完整的可执行文件。

编译器检查它能够判断的规则

编译器会检查语法、名字是否已声明、类型使用是否符合规则等问题。以下细小变化都可能让编译失败：

std::cout << "Hello, C++!" << '\n'  // 缺少分号

std::cout << "Hello, C++! << '\n';  // 字符串缺少结束引号

std::cout < "Hello, C++!" << '\n';  // 将 << 误写为 <

编译器只能根据实际文本报告问题，不知道编写者原本想做什么。报错位置有时会比根因更靠后：一个未闭合的引号可能让后续几行都被错误解析。

链接器组合各个已编译部分

当程序只有一个小文件时，编译和链接往往被一条命令完成，两个阶段看上去像一次操作。程序变成多文件后，它们的分工就会很明显。

例如，下面的头文件只声明了函数：

#ifndef MESSAGE_HPP
#define MESSAGE_HPP
 
void print_message();
 
#endif

定义放在另一个源文件中：

#include "message.hpp"
 
#include <iostream>
 
void print_message() {
    std::cout << "Linking complete" << '\n';
}

main 调用这个函数：

#include "message.hpp"
 
int main() {
    print_message();
    return 0;
}

可以分别编译两个源文件，再链接目标文件：

g++ -std=c++17 -Wall -Wextra -Wpedantic -c main.cpp -o main.o
g++ -std=c++17 -Wall -Wextra -Wpedantic -c message.cpp -o message.o
g++ main.o message.o -o greeter
./greeter

输出：

Linking complete

如果最后一条链接命令遗漏 message.o，main.cpp 仍可以编译，但链接器找不到 print_message 的定义，因而无法产生完整程序。

下面的观察器把构建过程拆成六个可以逐步推进的阶段。切换到“缺少分号”或“遗漏目标文件”案例，可以看到失败在哪一阶段发生，以及哪些产物不会被创建。

源代码的可移植性不等于二进制文件的可移植性

符合标准、不依赖特定系统扩展的 C++ 源代码，可以在不同系统上重新编译。已经产生的 .o、.obj、.exe 或其他可执行产物，则与操作系统、处理器架构和工具链有关。

因此，将项目交给另一个平台时，通常要交付源代码和构建方式，然后在目标平台重新构建；不能默认复制过去的可执行文件就能运行。

小节测试

准备开发环境并跑通第一条命令

一套最小 C++ 开发环境需要三样东西：

• 文本编辑器，用来编辑 .cpp 文件。
• C++ 工具链，至少能完成编译和链接。
• 运行入口，通常是终端，也可以是 IDE 的运行按钮。

IDE 会把编辑、构建、运行和调试放在同一个界面里。命令行则把输入文件、选项和输出文件明确写在命令中。两种方式没有本质冲突：IDE 内部也需要调用编译器和链接器。

先确认编译器可用

如果使用 GCC 工具链，可以在终端执行：

g++ --version

如果使用 Clang，可以执行：

clang++ --version

能看到版本信息，说明终端能找到该工具。如果出现“command not found”或“不是内部或外部命令”，应先完成工具链安装和路径配置，不要继续修改 C++ 代码碰运气。

使用 C++17 和常用警告

在 hello.cpp 所在目录中，使用 GCC 构建：

g++ -std=c++17 -Wall -Wextra -Wpedantic hello.cpp -o hello

使用 Clang 时，只需替换命令名：

clang++ -std=c++17 -Wall -Wextra -Wpedantic hello.cpp -o hello

这些选项的作用如下：

警告不一定会阻止构建，但它往往指向可疑代码。入门阶段不要养成忽略警告的习惯。当前程序很小，逐条理解并消除警告的成本最低。

运行并检查退出状态

在 macOS 或 Linux 终端中运行：

./hello

在 Windows PowerShell 中，可执行：

.\hello.exe

终端应输出 Hello, C++!。在 macOS 或 Linux 中，可紧接着查看上一个命令的退出状态：

echo $?

如果程序从 main 返回 0，这里应看到 0。退出状态与屏幕输出是两条不同通道：程序可以不显示任何文字却成功退出，也可以显示错误信息并以非零状态退出。

遇到环境问题时先缩小范围

当第一个程序无法运行时，可以按这个顺序检查：

1. 当前终端是否在 hello.cpp 所在目录。
2. 文件名是否真的是 hello.cpp，而不是 hello.cpp.txt。
3. g++ --version 或 clang++ --version 是否成功。
4. 构建命令是否产生了 hello 或 hello.exe。
5. 运行的是否是刚刚产生的文件，而不是旧目录里的同名文件。

如果使用 IDE，也可以用同样的问题检查：当前打开的是哪个项目，哪个源文件参与了构建，输出窗口中的第一条诊断是什么。

小节测试

使用标准输入输出完成交互

只输出固定文字的程序已经证明工具链能工作。下一步是让程序接收数据，完成一个很小的处理，再把结果输出。

C++ 提供了三个入门阶段最常用的标准流：

std::cout 和 std::cerr 默认都会显示在终端，但它们是独立通道。这个区分很实用：使用者可以把正常结果保存到一个文件，同时让错误信息仍然出现在屏幕上。

第一个完整小程序

下面的程序读取两个整数，输出它们的合计。它的需求可以简明地写成：

• 合法输入：两个以空白分隔的整数，且它们的和可以由 int 表示。
• 成功输出：两数之和。
• 错误输入：任一个值无法按整数读取。
• 成功状态为 0，输入错误状态为 1。

将代码保存为 sum.cpp：

#include <iostream>
 
int main() {
    std::cout << "请输入两个整数（用空格分隔）：" << '\n';
 
    int left = 0;
    int right = 0;
 
    if (!(std::cin >> left >> right)) {
        std::cerr << "输入错误：需要两个整数。" << '\n'

这个示例用到了变量和简单加法，此处只需按数据流程理解：left 和 right 保存输入，total 保存合计。类型、初始化和表达式的完整规则不在这里展开。

构建并运行：

g++ -std=c++17 -Wall -Wextra -Wpedantic sum.cpp -o sum
./sum

一次成功交互可以是：

请输入两个整数（用空格分隔）：
7 35
合计：42

>> 读取的是符合目标格式的值

std::cin >> left >> right;

可以按从左到右的顺序阅读：先尝试把一个整数放入 left，再尝试把下一个整数放入 right。空格和换行都可以分隔这两个整数。

如果输入是 7 35，两次读取都成功。如果输入是 seven 35，第一次整数读取就失败，输入流会进入失败状态。

不要默认输入一定正确

表达式 std::cin >> left >> right 可以被检查。外层的 ! 表示“没有成功”：

if (!(std::cin >> left >> right)) {
    std::cerr << "输入错误：需要两个整数。" << '\n';
    return 1;
}

这条错误路径做了两件事：把面向使用者的错误信息写到 std::cerr，然后返回非零状态。这比继续使用无效数据更可预测，也便于自动化工具判断本次运行是否成功。

小节测试

识别错误并有顺序地排查

编程时出现错误是正常现象。有效排错的第一步不是立即改代码，而是确认问题发生在哪个阶段。

这种分类不只是术语区分，它会直接决定下一步看哪里。编译命令尚未成功时，就不需要怀疑键盘输入数据；程序已经正常退出却结果错误时，反复安装编译器也不会修复逻辑。

编译时错误：从第一条诊断开始

一个引号或大括号缺失，可能破坏后面整段代码的结构。编译器会尽力继续分析，然后产生多条派生诊断。因此，先修复最早出现的一条，再重新编译，通常比从错误列表末尾向前猜更有效。

检查第一条编译诊断时，同时看该行和它前面几行：

• 字符串和字符引号是否成对。
• 小括号、大括号是否成对。
• 需要分号的语句是否已结束。
• 名字的拼写和大小写是否一致。
• 使用标准库名字前是否包含了所需头文件。

链接时错误：检查定义和构建输入

看到 undefined reference、unresolved external symbol 或意思相近的信息时，先回答三个问题：

1. 被调用的函数是否真的有一个定义。
2. 定义中的名称、参数形式和返回类型是否与声明匹配。
3. 包含该定义的源文件或目标文件是否真的参与了本次构建。

不要因为看到头文件中有声明，就认为定义也一定存在。声明说明“可以如何使用这个名字”；链接阶段还要找到对应实现。

运行时错误和逻辑错误：用预期结果定位

运行时错误需要可重现的输入。如果 sum 只在输入 seven 35 时走错误路径，就把这组输入保留下来，不要每次凭记忆重新输入一组不同的文字。

逻辑错误则必须依靠“预期是什么”来暴露。假如代码被误改为：

const int total = left - right;

它在语法上完全合法，使用 7 35 时也能正常退出，但会产生 -28，与“输出两数之和”的需求不符。如果没有先写下 7 + 35 应该得到 42，工具无法代替人发现这个差异。

用假设驱动修复，不要随机改代码

遇到不符合预期的行为时，可以使用下面的小循环：

这个方法会留下因果线索。一次随机改五个地方，即使问题消失，也很难确定真正原因，更难确定新变更没有藏下另一个问题。

小节测试

用测试确认程序确实工作

调试和测试都会发现错误，但它们解决的问题不同。调试往往从一个已知故障开始，目标是找到原因并修复。测试是有计划地选择用例，主动寻找程序与需求不符的地方。

一个可执行的测试用例至少要说清：

• 编译和运行的程序版本。
• 输入数据或操作步骤。
• 预期标准输出。
• 预期错误输出。
• 预期退出状态。

如果只写“试一下加法”，下次就无法确保执行了同样的检查。测试越具体，它越容易重复，也越适合在每次修改后再次运行。

从普通、边界和错误输入中选例

对 sum 程序，不需要穷举所有整数，但应挑选形成不同压力的代表用例：

边界不一定是“最大整数”。对这个入门程序，0、负数、只提供一个值、完全不符合整数格式的文本，都比反复测试几组普通正数更有发现问题的可能。

用重定向让命令可重复

在 macOS 或 Linux 中，可以用 printf 把固定数据送给程序：

printf '7 35\n' | ./sum

应输出：

请输入两个整数（用空格分隔）：
合计：42

还可以把实际输出保存起来，与预期文件比较：

printf '7 35\n' | ./sum > actual.txt
diff -u expected.txt actual.txt

diff 没有报告差异，表示两个文件相同。这里的关键不是必须使用某个命令，而是让输入固定、预期结果可见、比较可重复。在 IDE 或 Windows 环境中也可以先按用例表手工完成同样的比较。

修复过的问题要留下用例

假设某次修改让程序对 -8 3 输出错误，而修复后恢复为 -5。这组输入不应在问题解决后被丢掉，而应加入固定用例集。

以后每次修改都重新运行这些旧用例，可以检查已修复的行为是否再次退化。这是最简单的回归检查，也是项目积累经验的方式。

下面的实验室分成两轮。先根据故障发生的时机判断错误类别，再为 sum 程序组合一组覆盖普通输入、边界情况和失败路径的测试用例；提交后会指出遗漏的覆盖范围，并列出相应的输出通道与退出状态。

动手练习

不查看答案，先完成以下操作：

1. 从 hello.cpp 开始，将输出改成两行：Hello, programming! 和 Environment ready.。
2. 用 C++17 和警告选项构建程序，运行并检查退出状态。
3. 故意删掉第一条输出语句的分号，记录编译器的第一条诊断，然后修复。
4. 为 sum.cpp 运行用例 7 35、0 0、-8 3 和 seven 3，记录标准输出、错误输出和退出状态。

#include <iostream>
 
int main() {
    std::cout << "Hello, programming!" << '\n';
    std::cout << "Environment ready." << '\n';
    return 0;
}

g++ -std=c++17 -Wall -Wextra -Wpedantic hello.cpp -o hello
./hello
echo

小节测试

综合测试

应看到：

sum.cpp 的前三个合法用例应返回 0，合计依次是 42、0、-5。seven 3 应将输入错误信息写入错误流，并返回 1。