c++在公司里一般是做什么的啊

看不同类型的公司吧。
后台服务：就是提供普通的 HTTP 服务（逻辑用 C++ 写），RPC
基础架构：存储，数据库，区块链
各种机器学习算法的工程化：TensorFlow
游戏：用虚幻引擎制作的游戏，或者各种自研引擎。可能会有各种脚本绑定

做基础架构，做深度学习的训练推理框架

不过 Go 和 Rust 这种原生编译型语言一直在侵蚀 C++ 的应用领域，当然现在看来 C++ 的地位还算稳固，后面如何发展没人知道。

魔改一下 ffmpeg

@wangxn
@111qqz

这样看起来 c++的岗位似乎大多都需要一定的特定领域的经验啊

图形渲染引擎

cgi

补充：高性能网关，类似于 nginx ；客户端跨平台

嵌入式硬件

@zxCoder 这些经验算不得经验吧，学起来不就四五天

C++有些地方挺强大的，好像很少有语言支持泛型参数不是类型的，C++的模版可以把矩阵的行列数，还有物理上的量纲都做成强类型。

Cpp20 有了 Concept 、模块和协程以后又舒服多了。就是可惜在标准库演化太慢，又没有一个比较好的一键式包管理机制。

@agagega 第三方其实还行，linux 上 conan 我用的很舒服。

做显卡驱动的，用户态驱动是用 C++写的

@zxCoder #5 其实不能说“c++的岗位似乎大多都需要一定的特定领域的经验”，
而是 C/C++贴近硬件，需要很强的计算机体系结构的相关知识，
毕竟你搞个 web 前后端开发也需要 HTTP 的基础知识。

通信相关 c++非常多

机器人。

在公司编程不都是为了解决特定领域的特定问题么？

做低延迟交易系统

一般是写 C++ 的

搜索系统、推荐系统

卖萌的呗

@ospider 似乎很有道理

我在怀疑 现在还有这么苛刻的高性能需求吗？
一般是历史原因选 cpp 吧 rust go 不行不行吗

云计算很多服务都是用 cpp 。

我在工作环境用过的场景：
1. WebAssembly
2. Node 原生模块
3. Qt 桌面应用

基本上低延迟的交易系统都要是 C++

ue 开发

@ospider 听君一席话，如听一席话

cpp 和 python 很像，只会语言本身的话基本找不到工作

推广搜，机器学习框架，这块大厂的需求还是相当大的，不过也仅集中于大厂，而且也是卷的离谱

所有实时性要求高，资源要求苛刻的地方，都有 C++的身影

@liuidetmks #23 有，很多，只是国内相对没有那么多的岗位。比如 编译器、虚拟机、数据库、脚本 /图形引擎、浏览器、大型工业软件、大型数学工具箱、操作系统、机器学习框架、图形 /图像 /音频处理。

Go 的高性能侧重于“高并发”，C/C++的高性能侧重于“0 开销”，Rust 在 2010 年发布的时候，C++11 都要有了，Rust 前途无量但是生态需要时间。

游戏公司 后端用 c++的比较多。

火星车，
月球车

@Eagleyes 那个是用的 C，火星车上用 C++做的图像识别相关的，限制非常严格，几乎等同于带类的 C，不能用多态，不能用递归，不能用动态内存分配。

魔改 WebRTC，优化编码器，做视频通信或者直播软件，以及配套的媒体服务器

最近正在自学 C++，和虚幻引擎

我用 C++写 wasm 网页，我自己都觉得很奇葩。

@ospider #19 听君一席话胜听一席话

@wobuhuicode 兄弟，了解 dash 吗？

一般公司的基础件或者核心框架都会基于 C++来写，特点就是代码量较大，参与人数比较多。

@ospider 你搁这搁这呢

底层架构，或者需要处理效率的接口项目。

维护老的 MFC 程序

四七层负载 中间件

@Aresrun 如何看待最近比较流行的废话梗？反映了怎样的社会心理？

@shijingshijing 可是 C++ 的 template 才是 zero-abstraction 的精华啊

transaction framework, 搜索引擎等

@ipwx 。。。。哈哈 大佬的话不可信

没卵用了现在

搬砖 还能干嘛

怎么没有人提到做游戏呢

@liuidetmks
有的。。。我现在正在做的项目，医用便携式 B 超。里面有个控制器，内存 32KB 。。。。

@ipwx 别说 template，连 malloc 和 new 都不能用的，所有可能潜在有 undeterministic 特性的功能都不会用的，程序运行所需的 CPU cycle，memory，communication 等资源占用都要事先明确计算好，不得超过 50%。基本上就是用做硬件的思维来写软件。

@shijingshijing 神 tm template undeterministic 。

@ipwx [潜在]

只能说隔行如隔山，我要是告诉你，循环嵌套还约定不超过三层嵌套，你会不会更惊奇？

这些行业的规定和经验，都是经过一条条人命累计出来的。

@ipwx 航天要求时序确定。在地面上的能够完全确定机器的状态，所以内存是定死的。用动态内存会带来不确定时序。

@shijingshijing 火星车用的就是 C，而且全部是静态类型的的声明，

我现在做自动驾驶决策规划算法，也是 c++，实时要求很强，而且车企巴不得用更搓的处理器来省钱。

@tianming1992 可是，template 和动态内存毫无关系啊。。。倒不如说用了 template 让 C++ 省了很多需要动态内存申请的情况。不然怎么叫 zero-cost abstraction ？

另外 template poly 可以在不加虚函数表的情况下实现一定的继承多态之类的特性。

所以你到底会不会用 C++

@shijingshijing （正常写函数都不敢循环嵌套三层， 不然根本没法维护）

@ipwx 我理解的 template 会有 undeterministic 原因. 是因为使用了 template 后，代码是编译器生成的，（不同的编译器还有不同的实现方式）不是程序员手写的，可以了认为是潜在不可控的。

当然，C++ 构造函数，还有深拷贝，浅拷贝等等容易出错的坑。

所有 Linus 经常喷 C++是一门辣鸡语言

@bruce0 可是，C++ 的 zero-abstraction 是有规范的啊。

在 template 方面根本就没有 UB 。如果你认为不是手写的就是 undeterministic，我觉得你应该用机器码才行啊。

@bruce0 构造函数、深拷贝、浅拷贝，进化到 C++17 就是 move 语法等等。这些都是有规范的，一个能通过各种测试的编译器，用这些高级特性你都知道会发生什么。包括 -O3 。写出没有 Undefined Behaviour （遵守规范所以编译器也能给你完全能控制的代码）是 C++ 程序员重要的基本功啊。

@bruce0 哦对用机器码也不保险。

如果你用的是通用芯片，现代通用芯片在机器码的下面都有很多你“控制不了”的行为。比如英特尔的芯片微指令，一个机器指令其实是拆成若干指令，然后在芯片上有指令流水线（同一瞬间其实有多个指令的不同步骤正在执行）。这些指令“并行”会导致一些 data harzard 。当然，芯片帮我们处理好了。

但是因为是并行流水线所以会带来一些其他问题。比如遇到条件判断，现代芯片都会猜测这条语句的结果，然后提前进入某个分支执行。如果猜错了就“回滚”。对，分值预测就会导致你“执行时间不可控”。

还有比如 cacheline 、L1~L3 cache，atomic 指令，store buffer queue （在一个核上非 atomic 指令更新数据，另一个核不一定马上能看到）。这些都是你“不可控”的抽象。

----

现代计算机就是在一层一层你不可控的抽象上建立起来的。C++ 的各种语法和芯片上的这些复杂机制并没有本质差别。要理解、掌握这些抽象后面的原理，利用这些抽象才对嘛。

@bruce0 说起指令流水线和 data hazard 其实还可能会产生指令的乱序执行。比如老生常谈的

if (condition) {
with (lock) {
if (condition) { ...

这种 double-check-lock 在乱序执行面前会被虐成渣渣。解决方案是加入 memory fence 。

----

总之为啥 C++ 难，是因为太靠近硬件，需要掌握这些底层抽象才能用好。

@ipwx 我觉得无知者的道听途说根本配不上这么认真的回复啊

嵌入式，音视频，性能强相关的，android 和 iOS 的底层一些开发，也都是 c++开发好提供接口给上层用。

@ipwx 我工作不是写 C++的，只是偶尔用一下 C++，你说的很多深入的东西我也不太懂。我说不让用 template 的原因是我的理解，不一定正确（没有任何杠的意思，只是说一下我的看法）。C++相当于 C，确实会有一些容易出错的地方（特性太多了），不是这个语言不可靠，是写 C++的人，因为对 C++理解的不够深入导致的。有几个人敢说自己精通 C++，深入理解了各种实现细节。相对来说 C 就没有这么多容易出错的地方（因为特性少）

以前，看过一篇文章，说是 在汽车上写 C 程序，指针都不让用，不知道真假

https://www.amobbs.com/thread-5754354-1-1.html
关于下单助手 3.4.0 以后版本崩溃及内存异常等问题的情况说明
...
1 、原来为了集成各种查看实物图、SMT 贴片效果图，我们在这个小助手上集成了我们自己的一些 C++程序。
而这种 C/S 架构的方式，有 bug 的情况下，更新迭代也非常缓慢。
现在我们已经接入 EDA 团队开发的基于 WebGL 的在线图形引擎，用以替换掉原来开发的这部分 C++程序。
这样子，才能做到快速在线迭代更新。
...

@ipwx
@bruce0
@tianming1992

这里的 undeterministic 不仅仅是指技术上的，需要用 template 实现的函数大部分都是基础库之类的，实际作用是为了一次书写，适用多种类型，这种情况理论上是没问题的，可是在实际使用过程中，可能会碰到各种意想不到的问题，比如，嵌入式里面有很多 8 位，16 位，32 位不同类型的处理器，这时候假如函数里面使用了 Magic Number 作为参数，比如上限值，很有可能当参数为 32bit INT 类型没问题，但 8 位，16 位就会有问题。（你可以 Argue 说这是程序员素质的问题，但写函数的和用函数的人保不齐有一个没注意的，这样就会带来问题）

template 可以看作是一种语法糖，爽了开发，但是让后面的测试，追踪，certification 乃至出了问题做 Failiure Analysis 不确定性、复杂度和人力成本剧增，可能导致整个项目成本剧增，因此即使有这种场景，一般也是用宏定义来实现的，高可靠性的项目就是从技术上，管理上等各个方面来进行限制，尽最大能力保证不出问题，最好是从根本上消除产生问题的可能性。

这样来看，不能使用指针，不能动态分配内存，循环嵌套不能超过三层，不能使用递归等等神奇的限制也就合乎情理了。

@name1991 图像处理和路径规划用的“严格裁剪版 C++”，内存管理这一块 NASA 重新造了一套轮子，上两张图吧

@ipwx
他上 nasa 图了 确实写着不用 template 领先 1 分
该你反击了


（别问我，我就一不嫌事大吃瓜的

@shijingshijing 那行吧，只能说这是用 human labor 堆出来的重量级工程。

但凡是地球上跑的软件项目就不走这条路了，因为这要花太多人力资源。

@shijingshijing
我大概没见过哪个语言标准库 IO 部分比 C++的 iostream 更不讨人喜欢的了

游戏开发

@ipwx 很多代码都是自动生成的，还有很多是复用以前经过 certification 的老项目代码，测试的时候需要的人多。要想系统可靠，就必须尽量使用简单的基础模块，然后尽可能复用，宁可简单的东西复用几万遍，也不会为了省事儿弄个新轮子，NASA 自己造内存管理的轮子是迫不得已，不然也不会用的。

这些项目里面，R&D 的 effort 只占 30%，剩下的几乎全部是 Documentation，Test，Certifiction 。

做各种轮子

做低延迟系统

给使用的数据库加自定义函数

@shijingshijing intresting

在嵌入式中还是有一席之地的，例如汽车故障诊断仪中解析 CAN 、LIN 通信协议消息

@agagega 这倒是，我也不爱用 iostream 。特别傻逼。

@shijingshijing 那毕竟是 NASA，业务其实很集中。

我是觉得人类如果要征服星辰大海，这种龟速推进宇航器肯定是不行的。SpaceX 我估计不是这种写代码的风格，那种才可能快速市场迭代。。。所以你说 NASA 这种项目管理好不好？好也不好。。。

@shijingshijing 就这么说吧。按照我的理解。为什么写航天器的代码这么局限？大概是因为上天的芯片太弱，给犯错边界太窄了（包括发动机也是），所以才容易出事。

为什么上天的芯片太弱？整体科技水平还不够强的芯片不出错。
----

这是这个时代的局限性，我觉得也挺对。但是我也盼望将来上个天和出门打个出租车一样简单，那个时候的写航天器代码一定不会是现在这样了。

@ipwx 航天试错的成本太高，虽然火星车可以升级软件，但一开始就写好写正确更合适

@wangxn 嘛，所以才需要这么搞。

如果真有一天没有多大试错成本，或者这种慢吞吞的推进速度实在太慢了，那肯定就不会这么写了。

@ipwx

SpaceX 毕竟刚刚出大气层，还没遭受火星上各种宇宙射线，各种高能粒子轰炸，Elon Musk 本身把安全性看的也不高，成本和快速迭代占了较高的优先级，所以 Falcon 初期会各种炸，直到迭代出一个稳定的版本，NASA 经过了火箭，载人，登月，火星等各种毒打，思路是稳定优先。所以才会有 SpaceX 用 x86 来搞，NASA 坚持用 Radiation Hardened CPU，同样 Tesla 的车和丰田的车也可以类比。

外太空有很多其他因素要考虑，温差大（零下几百度到零上几百度），震动大，辐射大要防 SEU 处理，还要尽可能省电，优先保证安全性，还要绝对的稳定，还要做 N 多冗余设计，这么多东西要考虑，整个系统设计思路跟地球上其他系统完全不一样。

当然，随着发射成本的降低，现在也有把 HP 的高性能计算集群发射到空间站进行就地处理的实验了，好像已经有初步的结果，不知道没经过上述处理，只是简单的做 ECC 是否能保证结果的正确性。

@ipwx

芯片不是太弱，性能根本不是优先考虑的选项，首先要考虑的就是尽可能不出错，当前芯片性能完全是过剩的。但是地球上普通的芯片是不能直接拿去用的，需要定制耐高温，抗辐射等特殊设计的 CPU 。

https://en.wikipedia.org/wiki/RAD750

@ipwx
从另一个角度来看这个问题，写 Linux 内核也不让用 exception template iostream 这些东西，这不是 NASA 才有的局限。而且很显然 Linux 内核的局限更严格。

C++ 本来就有很多种用法，可以当稍微多一点功能的 C 来用，也可以当随便写 usafe 的 Rust 来用。
NASA 这么规定很可能只是因为技术负责人和 Linus 有相同的观点而已。

@CRVV 我寻思 Linux 内核也不是 c++写的，根本用不了。不过假设可以用，感觉内核社区也不屑于用这些特性

跑在嵌入式设备上的训练模型

@shijingshijing 我说的“太弱”也包含了“不能在太空稳定运行”这件事。

@CRVV Linux 内核不用 exception / iostream 是因为内核态上面的操作太奇妙，以至于不能用这些。可以理解。但是内核存在的意义就是让别的程序能够用 exception / iostream 这些高级玩意儿，更快开发程序不是么 233

至于 template 。那主要是 Linux 觉得 C++ 不利于这么大接近硬件的项目去兼容“傻逼程序员”。

其实软件工程从一开始就是试图用更高层的抽象去封装更复杂的显示细节。只有封装了才能让更“傻逼”的程序员更快的出活。内核就是干这事的，对于内核不能用 C++ 我觉得非常非常可以理解。要我说，用 C++ 也不过是权益之道，如果将来有一个高级抽象，可以有 C++ 的（执行时间）可靠性和 Java/C#（程序开发）可靠性，我举双手双脚赞成。
----

@shijingshijing @CRVV 所以我的论点倒不是说 C++ 多牛逼，大家一定要用 C++。而是觉得在 C++ 和 C 之间，C++ 提供的东西更多，理论上更容易出活。这个论调肯定没问题，不然游戏引擎为啥不用 C 写而用 C++ 写是不是？ C++ 开发速度 > 砍掉很多东西的 C++ > C 这是客观事实，不然 NASA 为什么不用裸 C 呢？

只是感叹这种抽象和硬件条件（包括物理学、发动机之类的制造水平）还不足以让星辰大海的征途一路通畅、高效快速前进罢了（叹息）

@shijingshijing

> SpaceX 毕竟刚刚出大气层，还没遭受火星上各种宇宙射线，各种高能粒子轰炸，Elon Musk 本身把安全性看的也不高，成本和快速迭代占了较高的优先级
-----

事实上我觉得这才是快速进入太空时代必要的。NASA 这种慢吞吞的风格才是权宜之计。

@ipwx

其实软件工程从一开始就是试图用更高层的抽象去封装更复杂的显示细节。
---
这一点你说的没错，事实上从抽象这个功能来讲，C++既需要做抽象，又要放不下底层，还要兼顾各种特性，于是造成了本身无比的复杂。现在普遍引入了 MBSE，基于 UML/SysML 在更高层级上建模，然后直接生成 C 代码，最终编译成机器码直接执行。这种模式已经是大的趋势了。UML/SysML 专门负责抽象，C 负责底层，就这样两层就够了。所以这样看，C++就没什么意义了，两头兼顾两头都做不好。这也注定了即使用 C++，也是在某个领域某个模块（比如图像视频处理）非用不可的情况下，才会使用，而且限制及其严格。

还有就是 NASA 并不慢，一套系统不是只要搞软件就能 run 起来的，在软件上面还有更高层的系统级的考量。基本的飞行系统架构，最顶层是飞行器系统，然后分解为推进子系统，动力控制子系统，环境控制子系统，电气子系统，电子子系统等等，这些子系统里面再进一步细分为机械模块，硬件模块，软件模块等模块，所以至少是三个层级。比如推进子系统，机械模块分为发动机喷嘴，燃料阀门，点火装置，压力检测等子模块; 硬件模块对应有发动机喷嘴控制器，燃料阀门控制器，点火装置控制器，压力检测传感器等硬件设备;然后才是运行在这些控制器里的软件模块。所以整体是一个非常庞大的系统，不止一个 CPU，不止一种 CPU，不像做个 App 什么的打开 IDE 就能写。

NASA 的系统工程和软件工程都是一流的，很多软件领域的概念和方法都是由 NASA 或者其他航空航天巨头首先提出，然后才慢慢引入到软件领域的，特别是测试领域，比如 MC/DC 。Elon Musk 纯粹是莽，没把安全性放在首位，如果一定要类比，我觉得 NASA 是传统类型的软件厂商，SpaceX 是互联网厂商。

@Caturra
这里有个因果关系的问题，因为 Linus 不喜欢 C++，所以内核才不用 C++。他不喜欢 C++ 的原因当然是 C++ 比 C 多的那些功能。
另外 Linux 内核已经开始用 Rust 了。

cuda

图像处理

视频处理

number-none.com/blow/john_carmack_on_inlined_code.html John Carmack on Inlined Code - Jonathan Blow's home page