@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 具体怎么生成的

发重复了，不好意思

可以先看这篇文章
被裁员后的法律指南：争取合法赔偿的实操步骤
https://selfboot.cn/2023/06/06/gpt4_lawer_helper/

搞不定的话，家属是律师，欢迎咨询
https://selfboot.cn/links

可以看这篇文章
被裁员后的法律指南：争取合法赔偿的实操步骤
https://selfboot.cn/2023/06/06/gpt4_lawer_helper/

家属是律师，欢迎来咨询
https://selfboot.cn/links

可以参考我之前的博客： https://selfboot.cn/2024/01/03/hexo_blog_speed/
http2 下放自己的服务下，然后和页面一起开 cdn ，这样会好些。
不过 font-awesome 的全部放自己的服务器下，还有些字体文件啥的，搞起来有点麻烦

@Hopetree 哈哈，和我一样～

@Hopetree font-awesome 确实，我也刚换，字体文件都不对。。我现在用 cloudfare 的 cdn ，也还可以

哦哦，刚问了下家属，事业编比较特殊，一般是要赔的，并且金额也很难谈。
如果私企，还有的回旋余地。。