重量级消息：MSVC STL宣布开源

MSVC STL开源

在今年的CppCon上，也就是这个月的16号，MSVC团队宣布开源旗下C++ STL实现。

消息称，STL全部实现代码将托管在GitHub上(朋友们，请用你们的智慧自行搜索)，其中包括了所有产品级代码，一个新的基于CMake的构建系统及README文件。大家现在就可以到GitHub上Clone一份代码下来，编译并尝尝鲜。

另外在MSVC团队Review所有的Pull Requests之前，他们还需要做一些其他的准备工作，比如添加一些测试套件代码。

问题与解答

问题：为什么要开源？

解答：基于一些原因，我们做出了开源STL的决定。通过将STL实现代码托管在GitHub上，可以帮助我们的用户跟随我们最新的开发进展，使用我们最新的代码改进，并帮助我们持续性的改善STL产品。随着C++标准的持续更新，每年都会有很多重量级特性在C++标准会议上被提出来，我们相信：将我们的产品以开源的方式来接受这些特性是非常重要的（例如，C++ 20中的Chromo和Format库就是很好的一个候选特性)。我们也希望能以开源的方式来反哺C++社区，将我们的STL实现共享给开源社区（例如，C++17中的charconv库）。

问题：你们使用什么样的授权方式？这对Visual Studio的用户有什么直接的影响吗？

解答：MSVC的STL实现通过Apache License v2.0 with LLVM Exceptions的授权方式来进行分发。这个授权方式也是最近才被Clang/LLVM/libc++工程项目中所创建出来的。

我们之所以选择这个授权，是因为libc++也在使用这个，它可以使库与库的之间的共享来的更加容易。要说明的是，MSVC的STL不会和libc++进行合并，它们依旧是两个单独的库，支持不同的平台和不同的数据结构。不过，如果libc++的维护者希望可以从MSVC的STL中拿点什么对他们有用的东西（例如，floating-point charconv），或者希望能和我们在新特性的开发中一起合作，我们将很乐意提供帮忙，他们完全不需要担心授权的事儿。

另外，作为MSVC STL库的使用者来说，你可能会担心：这个授权是否增加了我在使用过程中的一些法律责任呢？

没事！我们这次使用的Apache License v2.0 with LLVM Exceptions授权里清楚的宣示了：当你的代码中使用了MSVC STL并编译出Object Code（例如静态库，动态库或者可执行文件）时，你在分发产品给最终用户时，并不需要做什么事儿（没有所谓的法律责任和义务）。这也是我们选择这个授权的原因：我们尽量不中断/影响我们客户的生意，毕竟，咱们都是在同一个生态系统中对不对？

另外，再提一句：MSVC的STL实现代码中从Boost.Math和Ryu库中继承了一些代码，这些代码在Boost Software License v1.0的授权下使用。这个授权协议是另一个类似的开源协议，它也显式的排除了Object Code的分发情况。当然了，我们继承的代码在Apache License v2.0 with LLVM Exceptions授权下进行分发。

问题：除了MSVC STL，你们有考虑过开源MSVC工具集中的其他玩意儿吗？

解答：目前还没有这个计划。这次我们选择开源MSVC STL，是因为它与其他MSVC库和编译器不太一样。具体来说，STL是一个快速进化的库，并且它的发展由C++标准委员会管控，对于MSVC的其他库来说，情况就不是这样了。(一个C++库由C++标准委员会来管理，对于开源来说，确实是一件好事儿！这意味着，所有新的特性都会由C++标准委员会来指定和提议，我们不需要花时间和精力来考虑这些）。并且，STL库相对来说是一个更加简单的库，非常适合开源到社区，让大家一起来贡献代码。编译器可不一样，它不是那么的松散化。你想想啊，如果编译器开源了，那么你的C++代码的能否编译过，就得看开源贡献者的实现方式了。所以，编译器项目，我们还是让它老老实实的呆在我们的内部仓库里吧。

问题：后续的开发计划，有啥问题没有？

解答：确实是有那么一个：我们将会投入更多的时间和精力来完善我们的构建系统，测试套件和Bug追踪系统。这确实会Delay我们在C++ 20库实现上的一些工作。（老实说，我们才刚刚实现所有的C++ 17库的特性，所以，这个应该不是什么大的问题）。

这将帮助我们在持续改进STL的工作中变得更加有效率并最终更早的实现对C++ 20完整支持。

总结

说起STL那些个代码，我之前也曾无畏地看过一眼，当时我就决定了：我等还是退散吧。

这套东西，我先能用好，等我老了，没啥事儿干了，再研究研究也不迟。