最开始是因为在写PAT的时候google了一下“C语言中有类似stl吗”，然后看到了知乎上一个“纯C语言的工作有前（钱）景吗？”的问题里面韦易笑提到的云风、孟岩在07年Linus事件的时候关于C/C++的文章，看过之后受到了一些启发。
结论：全面的掌握C作为主要编程语言之一，另外两个是JAVA和PYTHON，放弃C++
下面贴一些摘录下来的话
“纯C语言的工作有前（钱）景吗？”下的两个回答
C，C++干资源紧缺，并且希望性能非常Predicatable的活，Python/Ruby做工具链，Javascript/C#/Java用于做界面和交互，SQL之类的DSL也要根据要求多多少少会一点。
很多大规模、靠增加计算资源就能完成的计算任务，并不适合用C++去做，Java、C#、Erlang等都要更实用一些。
C和C++的目的并不完全是为了压榨性能极限，更重要的是可预测性。比如说，程序用了10M内存，那就真真切切是10M；需要10ms做完这件事情，那只要OS分配10ms就一定能做完，即便是内存分配和释放的时间也是有界的。没有GC来打断，也没有VM的隐性和不可控的开销在其中。
如果任务需要达到计算单元极限的90%，只要肯花功夫总是能找到特定的表达满足这一需求。
这才是C/C++，以及未来的Rust有竞争力的地方。
作者：空明流转
链接：https://www.zhihu.com/question/30292024/answer/55484755
2005年以后，C++处在一个全面被代替的过程中：
- 底层系统：进一步回归 C语言，更强的控制力，更精确的操作。
- 网页开发：2006年左右，C++和 fastcgi就被一起赶出 web世界了。
- 高性能服务：varnish, nginx, redis 等新的高性能网络服务器都是纯C开发的。
- 分布式应用：2007年左右， C++被java和其他动态语言彻底赶跑。
- 游戏服务端：2008年后进一步进化为 C 和 脚本，完全看不到胖C++服务端了。
- 并行计算：2010年后，go, scala, erlang；而能方便同go接口的，是 C不是C++。
- 游戏引擎：没错 C++和脚本，但是这年头越来越多的开源引擎下，引擎类需求越来越少。
- 游戏逻辑：脚本
- 多媒体：SDL纯C，ffmpeg是纯 C，webrtc的核心部分（DSP, codec）是纯C的。
- 移动开发：早年C++还可以开发下塞班，现在基本被 java + objc + swift 赶跑了。
- 桌面开发：Qt+Script, C#等都能做出漂亮的跨平台界面。且界面脚本化趋势，不需要C++了。
- 网页前端：JavaScript, Html5, Flash
- 操作系统：FreeBSD, Open Solaris, Linux, RTOS, Darwin（OS X 底层），都是纯 C
- 虚拟技术：qemu / kvm （云计算的基石）纯 C，Xen 纯 C
- 数据库：MySQL (核心纯C，外围工具 C++)，SQLite 纯 C, PostgreSQL / BDB / unqlite 纯C
- 编译器：C/C++并存，不过编译器用脚本写都没关系，我还在某平台用 java写的 C/C++编译器
- 大数据：kafka, hadoop, storm, spark 都使用 Java
- 云存储：openstack swift python, hdfs java, 还有好多方案用 go
可以看出，即便 C++的老本行，GUI和图形（确实也还存在一些短期内 C++无法替代的领域，就像交易统里还有 COBOL一样），这年头也面临的越来越多的挑战，比如新发布的 Rust （如何看待 Rust 的应用前景？ - 知乎用户的回答）。可以发现，开发技术多元化，用最适合的技术开发最适合的应用是未来的趋势。而为这些不同的技术编写高性能的可控的公共组件，并轻松的和其他语言接口，正是 C语言的强项。所以不管应用层语言千变万化，对系统级开发语言C的需求还是那么的稳定，而这个过程中，哪里还有 C++的影子呢？
话题总结
所以说未来的趋势是：C x 各种语言混搭 的趋势，从TIOBE上 C++的指数十年间下跌了三倍可以看出，未来还会涌现出更多技术来代替各个角落残存的C++方案，C++的使用情况还会进一步下降。所以题主问学习纯C是否有前途，我觉得如果题主能够左手熟练的掌握 C语言，培养系统化的思维习惯和精确控制内存和硬件的技巧；右手继续学习各种新兴的开发技术，能够应对各个细分领域的快速开发，碰到新问题时能左右开弓，那么未来工作上肯定是能上一个大台阶的。至于C++ 嘛，有时间看看就行，逼不得已要维护别人代码的情况下写两行即可。
很多人觉得 java慢，C++快java 10倍以上已经是上世纪的事情了，现代的 java 只比 C/C++慢 70%，C++连1倍都快不了 java。也不要觉得动态语言慢，javascript只比C/C++慢 2.7倍。luajit只比 C++慢 5.8倍。在 jit技术发展的今天，C++在性能上离动态语言/java的差距越来越小，可易用性和生产效率上的差距，却和动态语言/java 比起来越来越大。各种编程语言速度差异.jpg
作者：韦易笑
链接：https://www.zhihu.com/question/30292024/answer/47513658
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
作者：韦易笑
链接：https://www.zhihu.com/question/30292024/answer/47513658
先贴一张几篇文章的关系图，之后是几篇文章中比较重要的摘录
文章关系.jpg
云风：C的回归
云风：看着C++远去；文后评论
我觉得，如下陈述，也算是所有支持OO的语言的通病吧：
所谓面向对象，从本质上说，是允许你去扩充这种语言本身的类型系统；所不同者，也就是究竟允许你的扩充可以在多大程度上去模拟原生类型。
各种支持OO的语言里，C++无疑是做的最为彻底的一种（我觉得不用加“之一”了_）；而其他如c#、java等等，则都做了更多限制——这些限制包括“禁止运算符重载”以降低类型模拟的层次和难度、“取消指针运算”以降低原生类型本身的复杂度（从而在另一个角度降低用户类模拟原生对象的难度），如此等等。
但，无论如何，只要在一定程度上“允许模拟原生类型”，那么同时也就提出了另一个要求，即：你必须模拟好该语言的原生类型，至少也要描述清楚你的类和原生类型间的不同之处。
对于java、c#之类“阉割版”（没有贬义）面向对象语言来说，这个模拟并不很难——虽然不可避免地有点额外的小麻烦。但对C++这个雄心勃勃的语言来说，情况就完全不一样了——你包装了个复数类？好吧，重载四则运算吧——它必须能够与其他已知未知的数值类型互动。
像java一样重载一大堆的equals？然后再在扩充了其他如有理数类时增加新的重载函数？
恶心。
于是，你不得不动用泛型（虽然java禁止了运算符重载，但基于现实需要，它很快也要支持泛型了）。于是乎，犹如老鼠拖木锨般，虽然初始目标是想做一个很小巧的东西，最后却发现自己不得不为了将其融于语言本身（或者说让人能以一致的风格使用），而不得不写出越来越多的东西。
这方面，java、C#要好不少，毕竟没有那么复杂的原生类型或/和不允许全面模拟原生类型。
但从本质上来说，情况并没有改变；反而是付出了性能和表达能力上的代价。
并且，java终于也要支持泛型了。越是追求技术，越是追求尽善尽美，OO语言用起来就越是痛苦——这个东西能否拷贝？暂时似乎还用不到，禁了吧，以后再写（不禁就是bug！）。
诸如此类本不必管的无聊问题，程序员却丝毫不能怠慢——为避免他人误中“边际效应”陷阱，在设计新类时，我们就不得不写出更多的代码。
从本质上说，OO语言是一个frame work，它封装了面向对象这个设计模式——c写的unix有个泛文件概念，一切最终可归结到输入输出上的东西都是文件：谁能说它不是面向对象的设计思路呢？所以说，c、汇编，都可以是面向对象的；设计者可以根据实际需要裁剪，给出最为精巧简洁的方案。
而OO语言，则强迫设计者使用语言给出的框架，做出完全面向对象的设计——java干脆不允许非对象的东东出现：这就在方案的可裁剪性上出现了问题。
尤其是对于C++来说：写一个类，就要考虑是否允许它如原生类型般工作；写一个算法，就要考虑它能否一劳永逸地处理所有类似问题；倘想解决所有这些问题，最终就会归结到模板；要动用模板，就要考虑编译器支持能力，要学习最新的泛型技巧……总而言之：一旦你想设计一个自给自足的、完美的类，不知不觉间，程序的设计重心就从“解决实际问题”转移到“写一个通用库”上了。
比如，在使用C时，仅仅为解决实际需要，为一个结构体写一个可完成工作的处理函数，是很自然很完美的；而到了C++中，这二者的结合有多丑陋，就不用多说了吧。
换句话说，就是使用OO语言，非常容易陷入“过度设计”这个泥潭；尤其是对那些工程经验不是很足、并且喜欢钻研底层的人来说。
即使工程经验很足，上面那种很实用的“半拉子类”，看起来也是极其恶心的。不如老老实实写成c结构体+一个处理函数的模式。
OO和泛型，本质上是用来写库的（而且是设计良好的库）；不问青红皂白就拿来做工程，怎么可能不恶心？虽然，用对了地方，它们真的很强大。
孟岩：Linux之父话糙理不糙
在9月份《程序员》杂志上刊登的一篇《微软架构师谈编程语言发展》的文章里，Brian Beckman直截了当地说，C++语言主要是用来开发别的语言的。这话片面一点，如果改成 “C++语言主要是用来支持别的语言的”，那就大体没错了。
做系统软件开发的时候，重要的是理解系统的运作方式，那些漂亮的抽象手法和高级特性是次要的。
对我来说， Torvalds的话其实是很中肯的，即使是用C++，也要尽可能搞清楚其背后发生的事情，这样在写low level程序的时候才会有把握。如果是设计应用级别的程序，就尽可能不用C/C++，把底层的事情都忘掉，专心专意做好应用层的设计才是正道。
版权声明：本文为CSDN博主「myan」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/myan/article/details/1777230
孟岩：用C设计，用C++编码
云风先是提了一下所谓C++带来的思想包袱（文言文曰“心智包袱”）问题，然后重重地引用了Linus的话：“关键是设计”，其实他是在暗示：好的设计C同样能做出来，不劳C++大驾；而C++一旦出面，就要让人背上额外的思想包袱。
我明确地表个态，在系统级程序设计中，事实就是这样的。
如果自己有朝一日重新跑回去写C/C++，我会怎么干？
就是采取“ C + Concreate Class + STL”的风格。说白了就是用C来设计，用C++来编码。
版权声明：本文为CSDN博主「myan」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/myan/article/details/1778843
后面两篇里没有特别想摘录的话，只放个标题在这
网友评论