刚好最近写 c++遇到个问题：
C++ string 意外修改之深入理解 COW 写时复制
踩了一个算是低版本 gcc 的坑。然后想了解下市面上还有写 c++的，编译器也还是 gcc4.9 以下的吗？
大家有没有推动 gcc 版本升级，比如用到 gcc8 以上？ 这样至少也能用到 c++17 的特性～
或者干脆升级到最新 gcc 或者 clang 版本，直接随时保持最新。这样能一直用最新特性。
如果没有升级，大家觉得最大的阻力是什么呢？

能用就行，又不是不能跑？
升级可能出问题，出了问题谁背锅？
做了老板不知道，白做？

所以还是苹果聪明，NSString 默认直接就是 readonly ，又保证效率，又不会出各种奇怪问题。C++就是需要满足太多不同人群奇怪的需求，导致效率上不去。

升 GCC 版本的话，一整套库也得跟着一块重新编译一遍，特别是某些库锁了版本的，老版本的代码在新的编译器上是否会存在问题或者潜在的问题，这个并没人保证，整体全部测试一遍的成本也比较高。另外就是 glibc/libstdc++这些你升编译器是否要跟着一块升？这个处理起来也很麻烦。

现在在公司维护的项目是 10 年启动的，release 版本用 gcc4.1.2 ，平常开发在 Windows 上用 vs2013 。日常想用 clangd 又因为环境各种问题用不上去。真不知道项目组那台编译服务器要是寄了，以后调这个环境得多累。

c_str(): The program shall not alter any of the values stored in the character array.

我是业余选手， 我用 12.2 ，蛮爽的

但保不住你用的一个函数，里面就改了呢。。

确实，低版本的编译环境配置起来都头疼。。4.1.2 那比我们的还古老，应该只能用 98 标准的吧。。

老毕登不听不学不用，这是最大的阻碍。

我把我们的整个库升级到了 8 ，你说的这些问题其实都还好。1. 很多库重新编译就好；2. 锁版本的库，一般升级库最新版本，如果没有，只能换一个库（还没遇见过）；3. 老版本代码肯定要适配更改，修复编译告警，错误；（这个很费时间），如果能编译过，基本不会有啥潜在问题，不过确实要测试，也比较费人力；4. glibc/libstdc++ 这个肯定要升级，不过上线环境高版本 linux 自带的就好，不用特殊单独升级

gcc 4.8.5 天天都想骂傻叉，字符串处理是真的蛋疼

效率上不去是说开发效率，还是运行啊，运行必然 c++效率更高吧

公共库里写 UB ，拖出来打。。。

高版本编译器是很爽，至少编译出错信息都很爽

人都换了几轮了，拖不出来了

我们也是这个版本。。

我这最大的问题反倒就是 4 ，上线的环境版本是定死的...自己折腾这些会很麻烦另外第 2 点，库锁了版本，最新版本和当初版本差距比较大的情况下，需要做很多额外的测试来保证库的版本变动不会影响到已有的代码（但比较困难，一般还是得跟着 Release Note 之类的去看有没有 breaking change ，或者一些行为上的变动），并不是说直接换最新版就 OK 的这个过程中，编译库算是最简单的部分了，麻烦的是测试成本很高而且你这一套做完也很难体现你这部分工作有什么产出（虽然说对未来开发是有好处的，但很难在当下立马就体现出来），对上不太好交代。

对，这里起始不止开发，还要运维一起帮忙的。我们就卡在运维这里，上线环境的编译系统，运维不支持高版本，虽然代码已经能编译过，但还是用老的。我们的机器中间腾挪过，现在倒是高版本 Linux 了，支持高版本 libstdc++ 了

多版本本来就可以并存的，你管别人干嘛，你自己个用就行了啊

直接换 clang14

建议你换 clang ，换成 clang 后，你会发现这个世界是多么的美好。

系统是 centos7 吗？用 gcc4.8.5 时我们一定会 preload 一个 so 把 string cow 禁用。另外我们也会把 chrono now()重写，gcc 原本的 now()每次都会 system call ，性能很差。

我现在就是自己编译用高版本，但线上编译部署老版本

是啊，clang14 很爽

不愿意写 c++了，看着到处是缺点还是 rust 香

跨平台，Linux 下面倒是 Clang 最新版了，真心舒服，但是 Windows 下面明明有已经用了 2017 ，但还得兼容 vs2013 ，连 C++11 都不能完全支持，就难受，问就是给我们提供库的其他部门还在用 13 ，最蛋疼的是他们发的库还需要 vcruntime140 ，也就是说他们连 15 也用了.

不破不立，直接推动更新技术栈，更换工具链和升级运行环境或者直接更换语言

换工作比推动升级简单。没有情怀的话，换个项目也不难

刚毕业的时候写了两年 VC6.0+MFC ，那时候都 2011 年了，我了个天。

说到技术栈，感觉 go 在编译工具链上还是很不错的

还有用 98 的呢。。11 应该还是主流，离谱

不能怪 GCC ，你把只读的 cast 掉，然后修改，不出 bug 就怪了。

哈哈，确实

c++觉得你清楚在干啥，一步步脱离他的掌控