在开始前刚好我有一些资料，是我根据网友给的问题精心整理了一份「C++的资料从专业入门到高级教程」，
点个关注在评论区回复"888"之后私信回复"888"，全部无偿共享给大家！！！
有些程序，是既可以用c++编写，也可以用java/python编写。
如果这类程序以前主要是由c++编写，后来逐渐变成主要由java/python编写，那么就可以说在这些领域中，c++被java/python代替了。
你随便问一个从业时间超过25年的老程序员，让他们给你描绘一下25年前c++"烈火烹油，鲜花着锦之盛"，你就知道c++有没有被取代了。
甚至在2005年，就能明显地观察到新出现的桌面应用，比如那时涌现的uml建模工具，已经很少有用c++编写的了。
这还是就桌面开发这个领域来说，至于其他新出现的领域，c++不是一触即溃，就是起个大早赶个晚集。
c++基本退回自己的老巢------系统程序开发领域，专注于啃老------啃c语言的地盘了。这是c++开始的地方，也是结束的地方。
结果还冒出来个rust跟c++抢。
操作系统对进程地址空间做隔离，就是怕进程通过指针破坏其他进程甚至内核里的东西。
c++程序的各个部分，每个部分（哪怕是再微不足道的部分）都可以轻易地通过指针破坏程序其他部分（包括最重要的那部分）。由此带来的bug，在当程序的不同部分是由不同的人编写，并且程序的不同部分由不同的线程同时执行时，会变得特别明显。
而当代c++程序员水平持续退化，有很多原因导致这一局面：
· 首先，相当多有能力的人被其他语言吸引走了，导致c++从业者"生源"劣化。
· 其次，c++社区的病态装逼文化导致很多选择c++的初学者把精力浪费在了学习没甚大用的++stl++及其衍生出来的更modern的特性身上，而对于真正重要的平台及业务知识的掌握程度令人发指。你能指望一群连编译时名字冲突都解决不了以至要被迫害妄想症似的在代码里写满"std::"的人解决并发环境下的运行时内存破坏问题吗？他吓都吓死了。
· 最后，c++的工具链确实落后，#include别人的头文件相当于直接让别人来改你自己的模块。这问题不到c++的++module++ 成为主流是没法解决的。