为什么感觉 C和C++ 不火了？|机器码|程序员|编程语言|编译器

为什么感觉 C和C++不火了？

你身边的所有电子设备内,都是C或者C++写的, 会淘汰吗，有本事你们别用电子设备，C语言和C++在互联网领域热度肯定不如Java、python、js，我现在做的是工业软件，在工业软件、机器人、自动驾驶、嵌入式等等工业自动化相关领域，C/C++仍然是绝对的霸主地位。我这里有一套单片机物联网资料大全，想自学的小伙伴把，我想白嫖已经三连打在评论区，我给你发哦。选择什么编程语言不是根据难易程度，而是生态，比如做工业软件开发也可以选择Java，毕竟Java可以非常简单的调用C++的代码，android里面应用比较多，但是做工业软件开发一个团队都是Java，那底层C++算法出问题谁去解决，一个团队编程语言越多扯皮也是越多。

首先C和C++是两个非常不一样的编程语言。C语言在系统开发领域地位非常稳固，几乎没有替代产品。应用层开发今年来略微有被Rust取代的迹象。C++由于支持的编程范式过多，导致不同水平的人写出来的代码质量差异太大，这给软件的稳健性带来了很大的问题。所以除了对性能有很高要求的系统，一般都会选择其他编程语言。Java之所以流行，一部分原因就是它比较死板，不太容易玩出骚操作。招来的Java程序员写出来的代码质量差异不至于太大。

长期来看，C++不会被淘汰，但是会变得小众。说穿了，C++只不过是C语言的升级版，但C语言中存在的弊端在C++中依旧存在，直到后来，1995年，Java被SUN公司正式推出，Java的一些特性很受程序员们的欢迎，比如再也没有C语言那样的指针，再也不用考虑内存管理，而且还有真正的可移植性，编写一次，到处运行，为了实现跨平台，Java中在操作系统和应用程序之间增加了一个抽象层叫Java虚拟机。用Java写的程序都跑在虚拟机上，除非个别情况，都不用看到操作系统。

编程语言只是工具

工具的意义在于被使用

c被发明出来，有其历史的局限性，当时的人，只能做到那个程度

科学技术要发展，就不可能局限在当时那个程度，所以才会有后来的c++

以及c++++--，也就是java最开始的名字

当然java在诞生之初，有各种问题，但是有问题就去解决问题，并不代表因为它有问题，所以人类科技就不要进步了

这里要特别感谢苹果和谷歌这种公司，尤其是在硅谷的那一干企业，因为正是他们的努力，才使得我们的编程语言越来越简单

比如java在一开始就提供了内存自动管理机制，也就是gc，有了gc之后，内存泄漏的可能性就大幅下降了，但是gc会有在执行时候整个程序暂停的问题，那怎么办？这是一个问题，就要去解决这个问题，苹果提出了arc，谷歌提出了将heap按照runner切割，java自身则在尽一切可能优化gc暂停时间，那到现在，即便是最暴力的缩短gc停顿时间这一维度上，都已经优化到了1ms以内，目前测试结果是16t的内存，可以在1ms以内完成，而且最大的暂停时间，只有区区的0.13ms[1]，然后这个还在不断优化中，并且在这个科技树上，还进一步衍生出了比如shenandoah，lxr[2]等多种短暂停gc的选择，并且这些gc策略，都由不同的公司完成，比如shenandoah主要有red hat红帽完成，而lxr则是由Google的人完成，这进一步促进了这个领域的繁荣和发展

那gc都能被优化到1ms以内，还有几个软件不能接受这个时长的暂停呢？

作为参照和对比，人的反应时间是0.2秒，也就是200ms以上，经过训练的运动员，可以达到0.1s也就是100ms，再低就不太可能了，然后人的眼睛，对于动画的敏感度，大概在60帧左右，也就是1/60，大约是16-17ms之间这样子，所以低于1ms的暂停，人是感觉不到的，你感觉得到的话应该去国家安全机构应聘，因为国家需要你这种超能力者

这是一方面

另外一方面，c++对于c的兼容性，在早期也是一个优势，就比如你用c++，调用c写的类库，比较简单，相比之下，用java的jni，就很麻烦，那jni就是ffi的一种，所谓ffi，就是调用其他语言的api的这么一个功能

比如你用java，要调用c写的类库，dll/so/dylib这种，就非常麻烦，jni用起来，既要懂c，又要懂java，那这个就明显阻碍了普通用户的使用

那ffi这一块这些年也是发展迅速，改善明显，现在普遍能够实现的就是，让用户不需要碰c等代码，通过工具，可以自动生成对应的语言接口，这样就可以让用户在不懂c的前提下，也能调用c编写的api，那native部分语言，大部分都提供了跟c兼容的方式，比如说swift的@_cdecl，那通过c，就可以将大部分语言连接起来，而且不需要用户了解c的知识，也能够将其利用

那这个就很方便了，就会出现一种情况，就是，我不需要知道你是怎么做的，我也不需要懂你所用的知识，但是这都不妨碍我使用你的劳动成果

ffi领域这些年的发展，主要就是要达成这个目标

这一块不管是苹果还是谷歌，都有自身相应产品，比如上文说的swift的@_cdcel，swift没有gc，所以跟c兼容起来比较容易，那flutter和java这种，需要的工作量就大一点，因为c没有gc，所以c画出来的内存，你是不是也要将其纳入gc扫描的范畴之内呀？你看，这里就有很多工作要做

但是经过七八年的发展，也基本上接近完工了，相关文档，直接看官方文档就行了，java的内容多一点，那有了ffi之后，你对有gc的软件性能不满意，你完全可以自己动手，用native语言实现一个，然后嫁接到你的代码中去

然后是第三个发展方向，就是将带有gc的语言编写出来的软件自身，编译成native

之前java等语言，跟c等native语言，一个实质性的差别就是编译产物，java编译成字节码，然后在执行时候，再将字节码翻译成机器码执行，而c，c++语言则是直接编译成机器码

那除了字节码以外，还有其他的中间码，比如llvm用的bitcode，当然原因不是为了跨平台，而是为了复用编译器后端，为动态类型和静态类型语言提供一个统一的编译器后端

那因为在这些代码执行的时候，多了编译成机器码这一步，所以启动时候相对较慢，而且运行时也相对大一点，因为多了一步工作嘛，那这个在某些场景下，就会降低用户的体验

所以将源码编译成机器码的需求，其实是存在的

那最早开始对这一块动手的，还就是谷歌，的安卓，因为客户端app对这些性能比较敏感，你下载一个app，又大又慢，用户肯定会有意见，早些年的安卓，被诟病说，不如ios流畅，就是因为jvm变种dalvik的缘故，时至今日，苹果在介绍swift的时候，还在畅谈aot和jit对比下，aot的好处

所谓aot就是将源码编译成机器码，而jit就是传统java那种方式，先编译成字节码，然后在运行时再编译成机器码再执行

那既然苹果和谷歌都认为，aot有好处，那这里就有需求存在，所以安卓后来就制作出了art，android runtime，安卓运行时，就是把app直接编译成机器码，就是aot