c++oding="utf-8" ?>
应使用g++而非gcc编译c++文件，因gcc不自动链接libstdc++且不启用c++名字修饰，会导致undefined reference错误；g++则默认完成编译、链接及abi支持。
用 g++ 而不是 gcc 编译 C++ 文件
直接用 gcc 编译 .cpp 文件会失败，因为 gcc 默认只认识 C 语言符号和标准库（如 libc），而 C++ 的 std::cout、new、异常机制等依赖 libstdc++，它不会自动链接。你大概率会看到类似这样的错误：undefined reference to `std::cout' 或 undefined reference to `operator new(unsigned long)'。
正确做法是统一用 g++：它不仅调用 C++ 前端，还会默认链接 -lstdc++ 和 -lc，并启用 C++ ABI 支持。
-
g++ main.cpp -o main—— 最简命令，一步到位生成可执行文件 -
g++ -std=c++17 main.cpp -o main—— 显式指定 C++ 标准，避免旧版默认（如 C++98）导致语法报错 - 如果混用 C 和 C++ 源文件（比如
main.cpp调用helper.c），仍用g++驱动整个链接过程，否则 C++ 运行时初始化可能缺失
为什么不能跳过 -c 直接从 .cpp 到 .o？
看似多此一举，但分离编译（g++ -c）在实际项目中几乎必用。原因不是“能不能”，而是“要不要”：
-
g++ -c main.cpp -o main.o只做编译+汇编，不链接，输出的是目标文件（relocatable object），不含入口地址、未解析外部符号（如printf）、也不带动态库依赖信息 - 多个源文件时（
a.cpp,b.cpp,util.c），先各自生成.o，再统一链接：g++ a.o b.o util.o -o program，避免重复编译未改动的文件 - Makefile 中依赖规则基于
.o，而不是直接从.cpp到可执行文件；跳过-c就没法增量构建 - 注意：
g++ main.cpp -c默认输出a.o（不是main.o），必须用-o显式指定，否则容易覆盖
链接阶段常见符号未定义错误怎么快速定位？
即使用了 g++，仍可能遇到 undefined reference to ...。这不是编译问题，而是链接器找不到符号实现，典型场景有：
- 调用了静态库里的函数，但没加
-L/path/to/lib -lmylib，例如：g++ main.o -L./lib -lconfig - 用了第三方头文件声明的函数，但忘了链接对应库，比如用
pthread_create却漏了-lpthread - C++ 模板实例化失败：模板定义在
.cpp里而非头文件中，导致链接时找不到具体实例（如MyClass<int></int>） - 函数声明与定义签名不一致，比如声明是
void foo(int)，定义写成void foo(int*)，编译通过但链接失败（C++ 名字修饰后符号名不同）
用 nm -C main.o | grep foo 可查看目标文件里是否含该符号（U 表示 undefined，T 表示已定义）；ldd ./program 能确认动态库依赖是否齐全。
生成的可执行文件为什么在别的 Linux 机器上跑不了？
默认 g++ 生成的是动态链接可执行文件，依赖目标系统上存在对应版本的 libstdc++.so 和 libc.so.6。常见失效原因：
- 目标机器 glibc 版本太低（如编译机用 glibc 2.34，目标机只有 2.28），
GLIBC_2.34符号找不到 - 目标机缺失
libstdc++（尤其 Alpine Linux 默认用 musl libc，不带 libstdc++） - 路径硬编码：程序里用了绝对路径打开文件，或
LD_LIBRARY_PATH没设对
临时解决办法：g++ -static-libstdc++ -static-libgcc main.cpp -o main —— 静态链接 C++ 运行时（仍依赖 glibc）；彻底静态化需换用 musl-gcc 或从源码编译，代价是体积暴涨且失去部分 POSIX 功能。
真正要跨平台分发，别依赖本地 g++ 默认行为；检查 readelf -d ./main | grep NEEDED 看动态依赖，比凭经验更可靠。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
