必须用g++编C++文件，因为gcc默认不链接libstdc++，会导致undefined reference错误；g++自动添加-lstdc++、启动文件和C++标准，默认启用name mangling与extern "C"兼容。
直接用 g++，别用 gcc 编 C++ 文件——除非你手动加 -lstdc++，否则链接会失败。
为什么必须用 g++ 而不是 gcc
虽然 gcc 能识别 .cpp 后缀并调用 C++ 前端，但它默认不链接 C++ 标准库（libstdc++）。哪怕代码只用了 std::string 或 #include <iostream></iostream>，gcc main.cpp -o app 也会在链接阶段报错：undefined reference to `std::cout' 或类似符号未定义。
g++ 的本质是 gcc 的封装：它自动添加 -lstdc++ 和必要的启动文件（如 crt0.o），还隐式启用 -std=gnu++17（具体版本依 GCC 版本而定）。
- 想用
gcc编 C++？可以，但得显式加：gcc main.cpp -lstdc++ -o app - 混合 C/C++ 源文件（如
main.cpp+utils.c）？统一用g++：它能正确处理 C 链接规范（extern "C"）和 C++ name mangling -
g++对.c文件也按 C++ 处理——所以别混用后缀，避免意外编译失败
基础编译命令的三种典型写法
实际开发中，90% 的场景只需要以下三类命令，区别在于是否分离编译与链接步骤：
立即学习“C++免费学习笔记（深入）”；
-
一步到位（最常用）：
g++ -o app main.cpp—— 自动完成预处理、编译、汇编、链接，生成可执行文件app -
分步编译（调试/多文件项目）：
g++ -c main.cpp -o main.o—— 只生成目标文件，不链接；适合多个源文件分别编译再统一链接 -
仅预处理（查宏/头文件问题）：
g++ -E main.cpp > main.i—— 输出展开后的代码到main.i，方便检查#define是否生效、#include路径是否正确
注意：-c 选项生成的 .o 文件不能直接运行；链接时若漏掉某个 .o，会报 undefined reference to ... 错误，而非编译错误。
必须加的几个关键选项
裸跑 g++ main.cpp -o app 虽然能通过，但容易埋雷。这几个选项建议写进日常命令：
-
-std=c++17（或c++20）—— 明确指定标准，避免依赖编译器默认行为（不同 GCC 版本默认标准不同） -
-Wall -Wextra—— 打开基础警告，捕获未使用变量、隐式类型转换等隐患；-Werror可选，把警告当错误拦住 -
-O2—— 发布构建必加，-O0仅用于调试（GDB 友好）；-O3不一定更快，有时反而因过度优化引入 bug -
-g—— 调试必备，生成 DWARF 符号信息；不加它，GDB 连变量名都看不到
组合示例：g++ -std=c++17 -Wall -Wextra -O2 -g main.cpp -o app
常见错误和对应解法
这些报错几乎每天都会遇到，原因和修复方式很固定：
-
fatal error: xxx.h: No such file or directory—— 头文件路径不对；加-I/path/to/include指定搜索路径 -
undefined reference to `xxx'—— 符号没定义或没链接；检查是否漏编译某个.cpp，或是否该函数声明了但没实现 -
error: 'shared_ptr' is not a member of 'std'——-std没设或设太低（shared_ptr是 C++11 引入）；改用-std=c++11或更高 -
segmentation fault (core dumped)—— 运行时报错，和编译无关；加-g后用gdb ./app查栈帧定位
真正难排查的往往不是语法错误，而是链接时符号名和实际定义不匹配（比如忘记加 extern "C" 包裹 C 库头文件），或者优化级别导致的未定义行为暴露——这时候 -O0 -g 和 -O2 行为不一致，就得靠 valgrind 或 UBSan 了。
