Qt 工作好找，但是好工作不好找，这个是没法跟互联网相比
其实是属于 C++的一个子方向（客户端）

最可怕是哪种人呢，就是对技术与框架停留在五年或者十年前，比如
１．用 c++的，还只会用 printf 或者 cout
而且是十几万行的大型应用软件

２．跟传输相关的所有东西，都就知道用 tcpdump 去抓包
他们不知道利用日志，不知道 wireshark。。

@sa2501 那么多新技术、新框架，你确定都要了解细节么？
每个人的时间与精力都是有限的，就算了解再深入也都是会有坑的。关键是遇到坑了，能不能把坑填了，这才是最主要的

但有个是事实，也就是被楼上大多数人看不起的 ppt 架构师，恰恰可以避免让大多数人少掉坑或者不掉坑
变化是常态，有坑也是常态

１．发送 raw h264 自然是不行，那么大数据量
大概率瓶颈是网络状况（网卡、路由器或交换机）。而且没有这么用的，哪有不编码传输的

２．低延迟？要找方案，起码给出要多低的延迟——50 或 100ms，或更低

@geligaoli 日常工作用，基本都是 Ubuntu 系列（不限于官方版本及国内出的改进版）

国内所谓互联网大中小厂，真的把整个行业都搞坏了

简单点吧，就是一些人很闲，就以为所有人都跟他一样闲；不带来额外价值的事情不要作，
什么叫有价值？手下可以带来技术提升，可以减少后期维护工作量，可以带来稳定性与性能

————lz 说的这个有什么用？屁用都没有。为了注释而注释，为了设计而设计，为了 oo 而 oo

对于老项目，
1. 能不改就不改，风格与已有一致
2. 关键是核心的接口与流程梳理

3. 与其要求所有接口加注释，不如要求逐步、渐进式重构
对大多数接口，只要保证命名规范（函数、参数、变量这些），就已经是足够好的注释
当然，对外接口（子系统或子模块之间）要提供接口文档

@canyue7897 你没看过开源的操作系统 /rtos 或浏览器的代码，就不要瞎逼逼，自以为是

当然，从这个事情我也就理解有个冷笑话了：
就是为什么国内各种大厂小厂开源的东西都不多——据说，是因为大部分都写的很烂，开源出来丢不起这个人

不知道为什么，985/211 的研究生，还是 IT 相关专业的研究生，写成这样的代码还有人各种洗，真的不可思议

1. vs
2. qtcreator

楼主说的这种呢，就是需要一个人，把整个框架搭建起来，定义清晰的接口，实现模块或子系统之间的接口层
然后子模块子系统内部，你管他怎么做

还有，建议没事不要用继承了，很容易滥用，不可控。组合配合清晰的设计，是最理想的

Java 这种为了抽象而抽象还算好的，毕竟灵活度没 C++高。恶心的就是，用 C++做的，然后为了设计而设计，为了抽象而抽象——简单点就是过度设计，用烂了，一堆坑，全是坑。

——————————————————————
更恶心的是没注释，没文档；变量命名用的全是缩写——有拼音缩写的，有英文缩写的
当然，代码量还大，将近上百 M 的代码量

这也是为什么很多人现在，毕竟喜欢 go 那样的风格。简单，清晰——语言层面提供足够多的基础功能

现在一些人的逻辑连基本常识都不如，

1. 所谓的一堆，一群，请问多大的样本？！
有统计学意义么。如果没有，就不要把个例当真理

2. 存在不是合理
为什么现在还一堆人认同所谓的存在即合理，然后就什么都不做，让其自然消亡？！
这个逻辑真他妈搞笑——若真是这样，现在应该还是大周大夏，数千年之前一样


用嘴巴抵制 996，总比嘴巴都不愿意动的人好
用行动去抵制 996，自然比只用嘴巴的好

本身问题的解决、大环境的改善就需要一个逐步渐进的过程。为什么一些人，就因为没有找到一了百了的方法去解决问题，就否决可以改善问题的做法与方式

罗马不是一天建起来的！

其实若 go 再成熟下（对不同平台的支持——主要是移动平台），做跨平台的客户端 go 应该是最合适的做法。UI 层与业务层通过 RPC/MQ 这样的方式提供接口或服务

UI 用各个平台的原生来做，也可以用 h5 的方式（如 electron 或 flutter ）

楼上很多人若无大型应用的经验就不要随便给建议，也包括对 C++一知半解的人

1. 大型应用
若都用原生开发的话，成本是极高的（包括不限于人力、开发与测试等等），当然，最大的是后期的维护成本。你要知道，就一端就有可能需要 5-10 个人的研发团队。光移动端就有 iOS/Android 主流的这两个。

而对于大型应用，一般根据公司的长远产品规划，逐步支持非移动端及智能硬件上也是会初步处于规划中的，比如 Window/OSX/Linux，以及智能硬件（如嵌入式的），若是这样的话使用原生的开发对于后续的运维与扩展（新功能、新平台）基本是不可行的，而且成本极高

而且还可能需要提供 sdk 给第三方（有这样的需求的）

2. 小型应用
这样的，随便是原生或是 h5 的方案或别的跨平台方案都是随便的，这个可以根据公司内部已有人员的技术栈选择就可以

3. C++跨平台应该怎么构建
对于这个的话，参考 google 维护的 WebRTC 就可以了——一个平台源码包括构建工具 >10GB

一般的做法，都是“C++库 + 平台接口层 + 原生（一般做 UI 与简单业务）”

稍微有些不一样的就是这个平台接口层的做法某，
a ） 比如可以直接用各个平台的原生语言封装一层提供接口
这种是目前主流的做法，WebRTC 也是这样。比如 Android 则是用 jni 封一层提供接口，iOS 就是 OC 一层；对于 Linux/OSX/Window 等，也是类似的做法。每个平台封装一层做接口

b ）可以网络的方式（如 IPC/MQ/RPC ）
这种更为灵活，这个做服务端是很成熟的做法；对于做大型客户端，有但是不太多

对于具体那种做法，是要根据业务进行综合评估的。

4. 对于 Qt 框架
其实 Qt 之前主要的应用场景是工业或嵌入式（如汽车电子、工控、各种智能设备）这些，对于跨平台这块，若 Qt 敢称第一，应该没有别的框架敢说第二。别拿基于 h5 的方案来说事，不是一个级别上的东西（包括性能、支持的平台等等这些）

做客户端，基于 Qt 好处的地方就是，
a ）提供统一的开发环境与构建方式
QtCreator + qmake/cmake，基本可以应付绝大多数场景与开发环境（ Linux/Window/OSX ）
输出根据自己的方案，可以是动态库或执行文件，都是没有问题的

b ）封装完善的基础功能
包括不限于常见的数据结构、网络（ http/ws 这些）、硬件接口等。简单点就是，很多基础功能不用自己维护，也不需要自己构建或寻找第三方的库（这个可以省事很多）

简单点就是，常用的基本都有提供


其实这最大的困难的地方就是，要用 C++做跨平台，团队内需要有非常资深的人可以 hold 得住整个框架，只要能够确保这一点，基本是不会有问题的。

另外，C++真的没有如外界所传的那么难。很多时候说难用，其实就是缺乏把握框架与方向的人，因为特性诸多，很容易给滥用。其实不管是什么语言，都存在这个问题，只是 C++更为明显而已。


注：本人维护过基于 C++/Qt 跨平台的客户端软件，源码量 > 50W 行以上，所以对于这块有足够的发言权。

详细情况可参考这里，
https://slack.engineering/introducing-nebula-the-open-source-global-overlay-network-from-slack-884110a5579

感觉有点意思，就是不知道性能怎么样。看了下介绍，似乎 slack 内部的服务器已经基于 Nebula 使用超过 2 年