C++未来最有潜力的行业和职位会是什么？

[sbldehanhan]

之前一直搞 C ，感觉没前途。后面想搞 C++，但时间不等人，想找个有前途的行业或者职位。有没有大佬给点建议？ 之所以选 C++，因为感觉垮到其他的语言跨度比较大，职业经历也有较大差别。C++还有点联系。

[SantuZ]

考虑高性能计算吗

[hankai17]

QT/MFC?

[Rxianbei]

我觉得应该在教学上

[Yeen]

行业软件？
游戏引擎？

[uriahliu]

视频编解码？

[sbldehanhan]

@SantuZ 只要能赚钱，稳定点就行。

[sbldehanhan]

@hankai17 这个有前途吗？ MFC 不是上古时期的东西了吗？哈哈

[jones2000]

编程语言只是一个工具， 关键是要选自己喜欢的行业。 如果不喜欢， 干了 2-3 年就没动力学下去了，基本就练废了。

[sbldehanhan]

@Rxianbei 当大学老师得博士学位吧？哈哈

[sbldehanhan]

@uriahliu 这是 C 吧？

[sbldehanhan]

@Yeen 做游戏不稳定吧？拼不过年轻人。

[sbldehanhan]

@jones2000 也就混口饭吃，很难找到自己真正喜欢的东西，没有那个天赋和条件。其实，我之前也是你这样想的。

[logic159]

网络协议、音视频编解码、系统底层驱动、游戏图形引擎等需要高性能的场景，MFC 就是上古过时的东西了

[cxh116]

赚钱行业，量化，高频？

[pi1ot]

自动驾驶

[levelworm]

目前来看游戏和量化还有音视频。

[tool2d]

游戏是全民娱乐刚需，来钱快，如果你游戏足够好，收入也挺稳定的。

但游戏大部分都是用 C#开发，和 C++关系没那么大，而且加班普遍严重一点。

传统行业 C++，估计空位不多。现在没人用 MFC 开发了，都改用 electron 前端写跨平台客户端了。

[sbldehanhan]

@logic159 目前的工作跟网络有点关系。您说的网络协议是个什么行业？主要做什么？

[Yeen]

@sbldehanhan 或者行业软件，金融，汽车，石油

[sbldehanhan]

@pi1ot 嗯，之前还有做机器人的联系过。感觉这两个是很新的行业。

[sbldehanhan]

@Yeen 汽车说的是自动驾驶吗？

[zjsxwc]

图像客户端
qml & c++ 用的人少
electron & rust 用的人多

[janus77]

为了钱途为什么非要 c++，你都转过一次语言了就不能再转一次吗，你底子是 c ，学其他语言不是轻轻松

[logic159]

看公司和行业，比如网络直播或者远程桌面用到的一些应用层协议，比如流媒体协议 rtp/rtcp/rtsp/rtmp/mms/hls 等等，还有更底层通用一点的比如 quic 、enet 、kcp 、udt 、SCTP 、Raknet 等等

[Yeen]

@sbldehanhan 工业软件，不仅仅是自动驾驶。但我认为行业比语言重要。

[tool2d]

我个人推荐 AI 行业，比如 https://github.com/ggerganov/llama.cpp ，核心是用 C 语言写的。

代码上线才仅仅一周，只是个雏形，就快 5K 的 star 了。

[sbldehanhan]

@janus77 比如说什么？ java 感觉也不行。go 吗？主要是跨度太大的话，上一段的工作经历用不上，不太好找工作。

[sbldehanhan]

@logic159 这些一般是公司的一个部门在做？还是行业内专门有公司在做？

[kita]

高性能计算都是 CUDA 的天下，你要说 OpenCL 或者 vulkan 还有些道理
但是和 C++没有关系，这些都不是给 SPMD 用的语言，而是 SIMT 的
上面什么 AI 项目用 C++的基本上是 compiler

[logic159]

@sbldehanhan 有网络直播、视频会议、云游戏、云桌面、视频监控等业务的公司会涉及到这些

[openmm]

网络方面还是有的呀，不是说腾讯很多还是用 c++嘛

[clemente0620]

转 RUST

[avv]

转 RUST 为它添砖加瓦，10 年后你就是多数人的领路人

[emSaVya]

我只能帮你排除掉一个 搜广推

[coderluan]

实际上上面提到大部分方向用的还是 C ，配个某个领域的技术 SIMD ，CUDA ，OpenXX 之类的，C++只是用少量特性而已，C 没前途不如 C++，那只是你选的按方向不对，你应该换个方向，但是这和是不是 C++无关。

[weidaizi]

并没有能力预测未来的潜力行业和职位，毕竟一周后的股市都预测不了。只能说说我职业生涯当中使用到 c++ 的职位：工业仿真软件，游戏引擎，交易系统。
语言其实只是很小的一部分，不同行业还需要不同的技能，比如做仿真 PLC 或仿真电路，你就得懂 PLC 和电路；做游戏引擎，3d 数学，渲染，shader 什么的也都要能耍的开，而且还要与做技美，特效，材质的同事能沟通的了。做交易系统，核心链路上是 c/c++，但是给外围用的可能就只是一些同步查询的服务，这时候会点 java/go 就很方便了。
所以想学就学呗，毕竟说不定啥时候就用到了，正所谓书到用时方恨少。

[Hsinyao]

做 infra ，写 C/Rust

[Cyshall]

我也觉得 c++除了特定领域之外，其余需要高性能语言还是 rust 比较好

[mobbdeep]

潜力就是维护上古项目

[opentrade]

你的知识面既浅又窄

[yangzhezjgs]

我认为是深度学习的推理 /训练引擎，深度学习编译器之类的，但是学习难度非常高

[sbldehanhan]

@opentrade 虽然，何以教我？

[sbldehanhan]

@coderluan C 有哪些好点的方向？要是不用换语言再好不过。

[sbldehanhan]

@Hsinyao 似乎不错。

[zackzergzeng]

同问，之前了解的比较多的就是 c/c++图像处理比较方便，延伸出来就是游戏引擎的开发，其他方向就不知道了

[GrayXu]

各种 infra 类，对性能敏感的都适合吧

[HENQIGUAI]

数据库内核

[e9pWeUbh9PGCnp95]

PL, AI compiler, HPC

[yyminmax]

科学计算，做科研吧。

[sbldehanhan]

@yyminmax 科研有啥单位？

[cnbatch]

音视频也有 C++的，虽然不多。

音频类：
曾经流行的 Monkey's Audio （ APE 格式）就是 C++写的，当然啦，这是他们公布源码后才知道的。尽管公布了源码，但仍然不是开源软件，因此翻身无望，毕竟没人愿意用了后不知哪天就收传票。

视频类：
H.264 ~ 266 ，标准委员会给出的 Demo 是用 C++来写的。
还有 x265 、libde265 也是 C++。
目前 x266 还没人做出来，于是标准委员会的部分成员就“基于”官方 Demo 做出了 vvenc 和 vvdec 。

为什么要打引号，是因为 H266 标准 Demo——VTM——恰好就是这部分成员做的（还有 HEVC 的 Demo——HM——也是他们做的），可以认为是标准委员会等不及，索性自己推出编解码器（当然啦，不能冠以委员会官方名义）。

[sbldehanhan]

@cnbatch 这个行业前景怎么样？薪资、发展。。。

[cnbatch]

@sbldehanhan 薪资不清楚，我也不是从事这个行业的。只是知道国内大厂有这方面的需求，也许从他们发布的招聘信息可以略知一二。
至于发展以及行业前景，那肯定不用担心，从诞生之初就一直稳步前进，毕竟高清视频压缩一直都是刚需。现在视频服务（流媒体、短视频等等）那么受欢迎，至少不会冷落。

[dryadent]

@SantuZ 转行这个欧克么

[bugmaker233]

从大家的评论就知道了 c++不同方向之间的差距有多大，生殖隔离不是开玩笑🤣🤣

[pppguest3962]

话说 mfc 这种框架，在 2023 微软的东西上面还能用吗？

记得当年学过一下子，好像就是把 win32 的过万数量的 API 包装起来，用 mfc 的逻辑去实现功能和 GUI 的关联

现在最新的 win 11 好像也是没有完全放弃 32 位的东西，

我的意思其实是问 mfc 还能不能在微软 2023 年，主流开发平台上用来做点儿什么…

很多年前长用 winxp 和 win7 时代，最后还是转 QT 代替 mfc ，记得他当年说过一句话，如果 mfc 逻辑调的好，那界面的用户感受真是非常流畅爽的，但后来跟手维护的程序员会非常的崩裂，同一种功能，有好多种逻辑实现方式

[cnbatch]

@pppguest3962 MFC 目前依然能够使用，只不过基本上不怎么更新，也没必要再用。

首先是，微软自己就推出了 C++/WinRT 这种包装物，用新标准 C++给 Windows API 做包装，间接表明不推荐再用 MFC 。须知道，MFC 推出的时候，C++仍未标准化，现在（ 2023 年）再去碰 MFC 的项目会特别不顺手。

再有就是，由于 MFC 已经停滞了很长时间，以至于缺乏对 High DPI 的支持。（ High DPI：也就是屏幕 DPI 设置为超过 100%，比如 4K 屏经常设置成 200%）。
结果就会导致使用 MFC 程序在高 DPI 环境下十分难看：要么一片模糊；要么编译时加个 DPI 适应文件或主动调用 DPI Awareness 让外观变清晰 + 自己手动计算各个 DPI 比率下界面各控件的位置与大小。要是不做计算保持默认，那么会导致原本对齐的控件变成没对齐，有些地方留空隔太少有些却隔得太多；自己计算但没算好的话，会导致程序界面控件错乱。

[cnbatch]

@cnbatch “补充一个，DPI 适应文件”的效果等同于自己调用 API：
https://learn.microsoft.com/en-us/windows/win32/hidpi/setting-the-default-dpi-awareness-for-a-process
https://learn.microsoft.com/zh-cn/windows/win32/hidpi/setting-the-default-dpi-awareness-for-a-process

[cleveryun]

c++编译 wasm 供前端性能要求高的地方使用，比如三维模型操作。