@leonshaw 人都换了几轮了，拖不出来了

@lts9165 高版本编译器是很爽，至少编译出错信息都很爽

@tool2d 效率上不去是说开发效率，还是运行啊，运行必然 c++效率更高吧

@wtof 我把我们的整个库升级到了 8 ，你说的这些问题其实都还好。
1. 很多库重新编译就好；
2. 锁版本的库，一般升级库最新版本，如果没有，只能换一个库（还没遇见过）；
3. 老版本代码肯定要适配更改，修复编译告警，错误；（这个很费时间），如果能编译过，基本不会有啥潜在问题，不过确实要测试，也比较费人力；
4. glibc/libstdc++ 这个肯定要升级，不过上线环境高版本 linux 自带的就好，不用特殊单独升级

@Noicdi 确实，低版本的编译环境配置起来都头疼。。4.1.2 那比我们的还古老，应该只能用 98 标准的吧。。

@leonshaw 但保不住你用的一个函数，里面就改了呢。。

@hello202311 来，推荐我家属，https://selfboot.cn/links ，靠谱律师一枚

不对，这个是 openapi 的 generator ，不过 OpenAI 的 sdk 貌似不是用的这个吧

@dayeye2006199 太 6 了，这个竟然也是开源了的
这里也提到原来 Swagger 以前也有生成的

Swagger Codegen to OpenAPI Generator

@kisnows 确实可以了的～

@kisnows This page contains the following errors:
error on line 13 at column 568: StartTag: invalid element name
Below is a rendering of the page up to the first error.

页面设计的挺好看的！

稳定 500 错误。
请求：
prompt: "高版本的 GCC 不再使用写时复制（ COW ）技术来实现 std::string 主要是因为 C++11 标准的引入。C++11 标准对 std::string 的实现提出了新的要求，特别是在多线程支持和性能方面，这导致 COW 不再是一个理想的实现策略。主要原因包括： 多线程安全：C++11 标准增加了对多线程的支持，强调了线程安全的重要性。在 COW 实现中，对字符串的读取可能需要检查引用计数，而修改操作可能导致数据的复制。这需要额外的同步机制来确保在多线程环境中的正确性，从而增加了复杂性和性能开销。 性能考虑：虽然 COW 可以减少内存的使用，但它引入了额外的开销，如引用计数的管理和复制检测。在多核处理器和多线程应用日益普及的背景下，这种开销变得更加明显。特别是在并发环境中，对共享数据的管理（如引用计数）可能成为性能瓶颈。 标准的统一性：C++11 之后的标准更倾向于简化和统一标准库的行为。摒弃 COW 可以使 std::string 的行为更加可预测，减少不同编译器之间的差异。 避免潜在的副作用：COW 实现可能导致一些非直观的副作用，特别是当程序员不了解背后的 COW 机制时。例如，一个简单的修改操作可能意外地触发整个字符串的复制，导致性能下降。 综上所述，虽然 COW 在某些情况下能够节省内存，但它在多线程环境中的性能问题和实现复杂性使得它在现代 C++ 标准中不再被采用。C++11 以后的实现更倾向于使用更直接、更高效、更易于理解和维护的内存管理策略。"

@dayeye2006199 哦哦，是我孤陋寡闻了，第一次见生成 sdk 代码的，不过还没搞清楚 stainless 具体怎么生成的

发重复了，不好意思