libstdc++ 和 libc++ 有什么区别，为什么新开一个 libc++

为什么不对现有的实现（例如 libstdc++）进行补充而新开一个 libc++​

libc++官方文档里有这么一段话

After its initial introduction, many people have asked "why start a new library instead of contributing to an existing library?" (like Apache’s libstdcxx, GNU’s libstdc++, STLport, etc). There are many contributing reasons, but some of the major ones are:

From years of experience (including having implemented the standard library before), we’ve learned many things about implementing the standard containers which require ABI breakage and fundamental changes to how they are implemented. For example, it is generally accepted that building std::string using the "short string optimization" instead of using Copy On Write (COW) is a superior approach for multicore machines (particularly in C++11, which has rvalue references). Breaking ABI compatibility with old versions of the library was determined to be critical to achieving the performance goals of libc++.
Mainline libstdc++ has switched to GPL3, a license which the developers of libc++ cannot use. libstdc++ 4.2 (the last GPL2 version) could be independently extended to support C++11, but this would be a fork of the codebase (which is often seen as worse for a project than starting a new independent one). Another problem with libstdc++ is that it is tightly integrated with G++ development, tending to be tied fairly closely to the matching version of G++.
STLport and the Apache libstdcxx library are two other popular candidates, but both lack C++11 support. Our experience (and the experience of libstdc++ developers) is that adding support for C++11 (in particular rvalue references and move-only types) requires changes to almost every class and function, essentially amounting to a rewrite. Faced with a rewrite, we decided to start from scratch and evaluate every design decision from first principles based on experience. Further, both projects are apparently abandoned: STLport 5.2.1 was released in Oct’08, and STDCXX 4.2.1 in May’08.

 

在最初的介绍之后，许多人问："为什么要开始一个新库，而不是为现有库做贡献？"（比如 Apache 的 libstdcxx、GNU 的 libstdc++、STLport 等）。有很多原因，但主要原因有以下几点：

多年的经验（包括以前实现过标准库）让我们了解到关于实现标准容器的许多事情，这些事情需要破坏 ABI（应用程序二进制接口）并对它们的实现进行根本性改变。例如，普遍认为，使用"短字符串优化"而不是使用写时复制（COW）来构建 std::string 对于多核机器来说是一种更好的方法（特别是在 C++11 中，它具有右值引用）。与旧版本的库破坏 ABI 兼容性被认为对实现 libc++ 的性能目标至关重要。 主线 libstdc++ 已经切换到 GPL3，这是 libc++ 开发者无法使用的许可证。libstdc++ 4.2（最后一个 GPL2 版本）可以独立扩展以支持 C++11，但这将是代码库的一个分支（这通常被认为对项目比开始一个新的独立项目更糟糕）。libstdc++ 的另一个问题是它与 G++ 开发紧密集成，往往与相应版本的 G++ 关系密切。 STLport 和 Apache libstdcxx 库是另外两个受欢迎的候选者，但它们都缺乏 C++11 支持。我们的经验（以及 libstdc++ 开发者的经验）是，添加对 C++11 的支持（特别是右值引用和移动类型）需要对几乎每个类和函数进行更改，实质上相当于一次重写。面对重写，我们决定从头开始，并根据经验基于第一原则评估每个设计决策。此外，这两个项目似乎都已经被放弃：STLport 5.2.1 发布于 2008 年 10 月，STDCXX 4.2.1 发布于 2008 年 5 月。

libstdc++ 和 libc++ 有什么区别​

libstdc++ 和 libc++ 都是 C++ 标准库的实现，但它们在许多方面有所不同。以下是它们之间的一些主要区别：

• 项目来源与维护者：libstdc++ 是 GNU 项目的一部分，由 GCC（GNU 编译器集合）团队维护。它通常与 GCC 的 C++ 编译器（g++）一起使用。相反，libc++ 是 LLVM 项目的一部分，由 LLVM 团队维护，通常与 Clang 编译器一起使用。
• 许可证：libstdc++ 采用了 GPL3 许可证，这是一种相对更严格的开源许可证。libc++ 使用更宽松的 University of Illinois/NCSA 开源许可证，允许在更多场景下使用该库，如在专有软件中。
• 对 C++11 及更高版本的支持：libc++ 从一开始就专注于支持 C++11 及更新的标准，因此对新的 C++ 特性的支持可能会更快。虽然 libstdc++ 也支持现代 C++ 标准，但在某些情况下，它可能会略落后于 libc++。
• 性能和实现差异：libc++ 和 libstdc++ 在某些实现细节上有所不同，这可能会导致性能差异。例如，libc++ 的 std::string 实现使用短字符串优化（Short String Optimization），而非写时复制（Copy-On-Write），这在多核机器上可能带来更好的性能。然而，具体性能差异可能因情况而异。
• 平台支持：尽管 libstdc++ 和 libc++ 都支持各种操作系统，但它们在不同平台上的集成程度可能有所不同。例如，在 Linux 系统上，libstdc++ 是默认的 C++ 标准库实现；而在 macOS 和部分 BSD 系统上，libc++ 是默认实现。
• ABI（应用程序二进制接口）兼容性：libc++ 和 libstdc++ 在 ABI 方面有所不同，这意味着使用这些库的二进制文件之间可能存在兼容性问题。因此，在选择一个库作为项目的基础时，需要考虑 ABI 兼容性问题。

总之，libstdc++ 和 libc++ 都是 C++ 标准库的实现，它们之间的区别主要在于项目来源、许可证、实现细节和平台支持等方面。在选择使用哪个库时，应根据项目需求和目标平台进行权衡。

https://notes.junorz.com/docs/backend/cpp/q-and-a