@yanyumihuang @wsseo 赠送礼物、打赏等行为，如果 app 本身不抽成也不走内购。别搞得好像苹果不抽成那些主播就能拿全款一样好吗，他们不如说以后打赏直接微信支付宝转账岂不是更好。主播都知道用了人家直播公司的平台就要接受抽成，怎么就不知道直播公司用了 app store 的平台也要接受抽成呢。当大家都是慈善家吗？
@yanyumihuang 三星的应用商店没什么影响力，但是三星在韩国非常有影响力。阴谋论一点来说，为了在韩国推广自己的应用商店，推动一个法案打压谷歌苹果也是有可能的。
另外主机硬件是做慈善，但是整体业务显然不是啊。假设一台主机售价 2000 元，我们就算亏本 10%，200 块好了。两个 3A 售价 700 元，就可以抽成 210 元了。平均下来哪里亏损了。更何况主机一个型号卖 5 年，就算前两年亏损，后两年卖硬件甚至还能赚钱。苹果虽然也是抽 30%，但是显然以当前定价，App Store 营收肯定不能抵消硬件亏本卖的钱，所以这种商业模式肯定是不行的。

@wsseo 基本知识：打车等购买现实服务不走内购，转账不走内购，移动支付不走内购，网购也不走内购，甚至在淘宝购买其他电子版软件都不走内购，只有 app 内购买的用于该 app 的“电子商品”走内购。赠送礼物、打赏等行为，如果 app 本身不抽成也不走内购。

@yanyumihuang 冷知识，三星是有自己的应用商店的。堡垒之夜被苹果和谷歌下架之后，就跑到 galaxy store 上架了，甚至 galaxy store 官网现在还在宣传"Fortnite is still here and not going anywhere. Download now at Galaxy Store."。

@yanyumihuang 主机能卖软件赚回硬件的钱，必然是软件的销售额要足够大才行，更何况主机一套硬件用五年。以目前手机软件的定价和更新频率，苹果降到三千就完全是在做慈善了。所以要么苹果做慈善，要么 app 涨到 3a 价格，要么维持现状，有什么问题吗。

@xing7673 阴谋论一下，这个法案说不定是三星搞的。欧洲的手机厂商感觉都差不多半死不活了。

@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++出现的内存错误。也许是他们的程序员脑子也不行吧。