@yanyumihuang 那很多 app 恐怕就要提价到 3A 的水平了。

@wutiantong 我想到了一个生命周期的例子，但可能不太贴切。就比如有这样一个多层嵌套的结构：
std::vector<std::vector<...std::vector<int>...>> mat;
访问这个 vector 的某个元素就需要, mat[0][0]...[0]。为了可读性或者其他目的，C++里可能会设置引用，int &first_element = mat[0][0]...[0]。或者 std::vector<int> &sub_mat = mat[0]...[n]
但 C++中，你仍然能对这个 vector 的某一层进行操作，比如 push_back，但是当 vector 的容量达到一定程度时，vector 需要扩容时，就可能导致引用失效。因此对 vector 操作时，C++程序员必须思考和检查有无指向 vector 内部的引用和指针。
但在 rust 里，对 Vec 内部的引用，因为 get 函数返回的引用的生命周期依赖 Vec，因此会同时使 Vec 在内部引用周期结束前都保持只读状态，因此如果在引用周期结束前执行了 push 等操作，编译器就会直接报错。因此在 rust 中，就免去了人工思考能否 push 的过程。

@mingl0280 C++的问题是，当你以为你会这个特性的时候，实际上这个特性在某种情况下又会有别的行为，连编译器不同都可能会有不同的行为，连正常的、简单的语句几乎处处都可以有陷阱。就请问您有多少种特性是能确定的，保证能考虑到各种情况的？你是每写一句代码就要查怎么用吗？

@RobberPhex 这也是我觉得 rust 优于 c++的原因，在写 c++的时候我需要花费大量精力去检查是否有 UB 等算是附属性困难的问题。而 rust 中，在 unsafe 以外我就完全不需要考虑这些，只要让编译器通过即可，甚至可以差不多像托管语言一样编程，称之为解放感也不足为过。

@RobberPhex 我觉得你这结论不对。开发中处理本质性的困难就已经很麻烦了，可是如果编程语言 /工具又增加了附属性的困难，那不是难上加难。这也是为什么有的语言可能开发效率高，有的语言可能开发效率低。

@mingl0280 请问敢说自己精通 c++？

@newmlp 注意看，我说的是有 gc 的语言不会内存泄露，而没有说 rust 不会内存泄露。

@3dwelcome 你的意思是，没有不好用的语言，只有写 bug 的人呗。但是前半句话就不成立，不然同样是底层高性能，为什么不用 C ？
C++的问题不是有 UB，而是你用正常的代码写着写着，不知道什么时候就 UB 了，这才是 C++恶心的地方。而其他语言易用之处也就在于此，就是正常的代码的行为都是“符合预期”的，要用指针等危险代码就要用特殊语句。
就比如你说的那个 memcpy overlap 的问题，rust 里，专门把 memcpy 拆成了 std::ptr::copy 和 std::ptr::copy_nonoverlapping 。就相当于跟你说清楚，有可能 overlap 的情况用这种，你能保证不可能 overlap 的情况用这种。

@3dwelcome 我主要想说的是，内存安全漏洞占所有漏洞的比例一直是很高的，这反应的是 c++现有的范式及辅助工具等，并不能防止这些错误，而不是说 c++漏洞多。所有语言都能写出有漏洞的代码，但是有的语言就能保证（在 safe 的范围内）不犯某些错误。比如有 gc 的语言，你就不会内存泄露，而 rust 编译器保证了内存安全和并发安全（ unsafe 以外）。
“人经验上去了，遇到的坑多了，BUG 自然就少了。”才是无稽之谈，世界上就没有不犯错误的人，更不乏反复犯同一个错误的人。

@3dwelcome 就比如搜索 chrome 内存安全，就可以看到一篇报道，指出：自 2015 年来，use-after-free 占 chrome 安全漏洞的 36.1%。内存问题仍然是 c++的主要问题之一。

@3dwelcome 并不是，如果这些泄露检测工具那么有用的话，windows 和 chrome 也不至于总能找到内存问题吧。微软和谷歌的报告也指出了，他们产品大部分的漏洞都是内存安全导致的。而换用 rust 后，也都有称赞 rust 确实解决了大部分内存安全的问题。

@wutiantong 也许说 UB 确实不准确，但是问题就在于 c++并不阻止你使用再次使用 moved 的对象，即使它有潜在的问题。就像 c++不阻止你再次使用 deleted 的指针。虽然某些次运行不会出错，但是总有出错的时候。
而且，c++就算用值语义，也不能避免内存错误，但是 rust 能检查出来。就比如有 std::vector<Foo> a={...}; const Foo &b = a[0]; a.clear();这时候就有潜在的悬浮引用 b 。

@ipwx 我是没看过哪个 c++的编译器能检查悬浮指针的问题的。微软和谷歌这些大量程序员用 c++的公司，都承认改用 rust 后，解决了绝大部分用 c++出现的内存错误。也许是他们的程序员脑子也不行吧。

@wutiantong C++也是有问题的，比如一个对象之前已经被 std::move 了，但 C++不会阻止你去访问一个 move 掉的对象，之后再调用这个对象的行为是一个 UB，相当于一个悬挂指针。
rust 显式定义生命周期的目的，不是为了计算对象什么时候 destroy （这一点 rust 也是 RAII ），而是为了保证你在函数内访问或返回一个对象的引用的时候，这个引用一定是 valid 的。

@GeruzoniAnsasu 就比如 c++里经典错误，一个重载函数签名有 int foo(bool a)和 int foo(std::string b)，请问 foo("abc")调用哪个版本。c++语法中就有很多陷阱，因此非常依赖 more more more effective c++之类的最佳实践。
如果让新手写 c++，出来的代码可能能编译能跑，但实际上却有存在内存错误或 UB 等等潜在问题，算不算友好呢。rust 除了强制所有权、引入了抽象数据类型(Option 、Result)等，我觉得最大的优势就是能编译的时候检查许多内存错误，只要改到编译器通过就行。

qq 就至少会自己判断终端，是微信太垃圾了。

@wyfyw 共享和镜像前两年随航就支持了。

@ysc3839 原来如此，但是我还是觉得如果真的要去掉 gil，这些静态对象的计数不是最大的问题。