虽然说没有银弹，但是我感觉 c++完全可以设计成更友好，开发速度更快的语言

[zxCoder]

c++大佬别杠我，不可否认的是 c++学起来实在太难，写起来实在太慢

实际上很多东西感觉完全可以反过来吸收别的语言的优点

[junkun]

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

[3dwelcome]

@junkun "世界上就没有不犯错误的人，更不乏反复犯同一个错误的人。"

不不，这锅不能让 C++语言来背，并不公平。

我个人觉得，无关语言，而是写代码那个“人”，才是产生 BUG 最重要的主体。并不是语言之间有高下。

可能你在以往项目里，遇到了很讨厌的 BUG，非常难查，所以顺带着厌恶 C++。但是也有很多老项目，运行的非常良好，代码结构清晰。就看开发的人，有没有心把代码写好，易维护了。

[3dwelcome]

C++目前作为万能胶水语言，在各个领域都占有一席之地，如果是多平台高性能开发，就很难完全避免 C++。

正因为 C++被定位”高性能“，和机器运行机制最接近，那些影响性能的动态类型，都被尽可能的排除在外（游戏行业为了追求帧率，还把 RTTI 都关掉），结果就是无比复杂的编译期推导，这也是过于追求性能的代价。

内存泄漏也是一样，GC 很早就提出 C++ std 预案了，一直悬而不决，肯定不是做不了，而是加了必然会影响性能。

游戏里有一种叫帧内对象的内存池。有些内存分配的对象，真不用去管什么内存泄漏，无脑用就可以。三帧后，整个内存池都不在了，必然会被回收。

[3dwelcome]

关于 UB 我也想说一句，你遇到的坑，基本前人都遇到过。

我最近遇到的一次，就是 memcpy 结果不稳定，网上一查，写明了 If the objects overlap, the behavior is undefined.

很多时候真是吃一堑长一智。

[irytu]

Rust 来了！

[piping]

c++ 设计就是工具的问题，跟人无关，这个工具门槛高，不好用，但以前没有可行的替代品，现在有了，就是 rust，这不是未来，是已经发生的事，以后只会越来越明显。

[piping]

未来写 rust 代码的门槛只会越来越低，现在很多领域都有成熟的 rust 代码库，就算自己造论子，大部分时候 .clone() 完全足够使用，完全不需要学习 lieftime，rust 2021 版本马上要出了，现在的 rust 写起来就和脚本一样，速度还特别快

[junkun]

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

[abcbuzhiming]

@Kingfree rust 在解决 c++痛点的同时又加了一堆自己的痛点上去了。。。

[newmlp]

@junkun 内存安全不等于内存泄漏

[junkun]

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

[mingl0280]

@junkun 说白了就是你对 C++的 UB 不熟悉然后又要怪 C++难写呗。
就是又要骚操作又要装成专家，你这么搞怎么可能不出事？

[wutiantong]

@Austaras “语法可能性”就是指 c++的语法 feature 多呀，你真的可以多了解了解。
比如你特意提到的 adt，我去搜了一下，好像就是 std::variant ？ c++的一个小工具类原来在你心目中有那么厉害？

[wutiantong]

@Austaras 另外，你说的引用飞来飞去确实会令人头大，所以我一直在告诉你，一个可能是你的代码结构有问题，二个是如果你用 C++善用值类型封装，你就不会看到引用飞来飞去了。

[wutiantong]

@lesismal 学 C++可能是比较难的，但也没有你们说得夸张（很多事情真的会被无限的夸张渲染），不用管上古语法和 boost，直接从 C++11 学起，除了 C++ Primer 还推荐看这些：
1. https://www.stroustrup.com/tour2.html
2. https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md

[wutiantong]

@no1xsyzy 很有趣的样子，谢谢推荐

[mmdsun]

C++的升级版 C++++ = 微软的 C#

[bluesenzhu]

@junkun c/c++也有，memcpy()和 memmove()

[junkun]

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

[RobberPhex]

我 off topic 一下哈。

《人月神话》书中提了软件工程的复杂度主要来自两个方面：本质性的的困难、附属性的困难。

题主所属的，C++过于复杂，可以从其他语言吸收特性等，都是附属性的困难。

但需要注意的是，“没有银弹”的主要原因，是本质性困难的存在。本质性的困难难以解决，因为大部分的活动是发生在人们的脑海里，缺乏有效的辅助工具：
* 复杂性（ complexity ）：软件要解决的问题，通常牵扯到计算步骤，这是一种人为、抽象化的智能活动，多半是复杂的。
* 隐匿性（ invisibility ）：尚未完成的软件是看不见的，即使利用图标说明，也常无法充分呈现其结构，使得人们在沟通上面临极大的困难。
* 配合性（ conformity ）：在大型软件环境中，各子系统的接口必须协同一致。由于时间和环境的演变，要维持这样的一致性通常十分困难。
* 易变性（ changeability ）：软件所应用的环境常是由人群、法规、硬件设备、应用领域等，各因素所汇集而成，而这些因素皆会快速变化。

所以编程语言的发展还是有必要的，在解决附属性困难上很有必要。
但是如果我们要大幅提升开发效率，目前比较好的方向是 AI 、形式化验证等。现阶段，编程语言的进化在解决本质性困难上用处不大。