链接C++程序时是否可以用C标准库替代C++标准库

可以实现，不需要用-nostdlib移除全部标准库，g++、clang均提供了专门的编译参数-nostdlib++，作用就是仅跳过C标准库（libstdc++/libc++）的链接，保留C标准库的正常链接。
需要注意两个前提：

• 你需要主动禁用依赖C标准库实现的语言特性，或者自行实现对应的支撑逻辑：比如默认的new/delete运算符、异常处理、RTTI（运行时类型识别）的实现都存放在C标准库中，如果你要使用这些特性，要么自己实现对应逻辑，要么添加-fno-exceptions -fno-rtti参数关闭这两个特性，否则会出现链接错误。
• 不要调用任何std命名空间下的C标准库组件（比如std::vector、std::string等），这类组件的实现也依赖C标准库。

示例编译命令如下：
g++ -nostdlib++ -fno-exceptions -fno-rtti your_code.cpp -lc

可行性 #

该方案确实可以大幅降低C程序的体积，最终生成的二进制体积和纯C编译的结果几乎没有差异，同时你可以无额外开销使用命名空间、强类型检查、重载、constexpr编译期计算、非虚函数类等纯语言层面的C特性，不需要付出额外的内存成本。

存在的缺点与未普及的原因 #

• 不是完全零成本：你需要额外处理C运行时的支撑逻辑，比如如果要使用new/delete需要自行基于malloc/free封装，同时需要非常清楚C各个特性的底层依赖，避免不小心引入依赖C标准库的代码，对开发者的C功底要求更高。
• 特性收益有限：禁用C标准库之后，C最常用的标准库组件（智能指针、容器、算法、字符串处理等）都无法使用，你能用到的C++特性优势非常有限，很多开发者认为为此调整开发规则、踩坑的性价比不高。
• 工具链稳定性问题：很多嵌入式小众架构的交叉编译工具链对C++的支持度远低于C，容易遇到编译器bug、特性支持不全的问题，稳定性不如纯C开发。
• 团队与生态惯性：嵌入式领域的C生态非常成熟，大量成熟的驱动、组件、参考代码都是C实现的，多数嵌入式开发团队的技术积累、开发规范也都围绕C构建，切换到这种阉割版C++的学习、迁移成本不低，反而不如直接用C省心。
• 额外的配置成本：你需要在编译配置中主动关闭异常、RTTI，添加-nostdlib++参数，还要做额外的体积检查避免误引入C++标准库的代码，比纯C编译多了不少配置工作量。

内容的提问来源于stack exchange，提问作者jaja360