还在用 GCC4 版本的 c++ 主力语言小伙伴，来一起吐槽下？

[xuelang]

刚好最近写 c++遇到个问题：

C++ string 意外修改之深入理解 COW 写时复制

踩了一个算是低版本 gcc 的坑。然后想了解下市面上还有写 c++的，编译器也还是 gcc4.9 以下的吗？

大家有没有推动 gcc 版本升级，比如用到 gcc8 以上？ 这样至少也能用到 c++17 的特性～

或者干脆升级到最新 gcc 或者 clang 版本，直接随时保持最新。这样能一直用最新特性。

如果没有升级，大家觉得最大的阻力是什么呢？

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

[tool2d]

所以还是苹果聪明，NSString 默认直接就是 readonly ，又保证效率，又不会出各种奇怪问题。

C++就是需要满足太多不同人群奇怪的需求，导致效率上不去。

[wtof]

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

[Noicdi]

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

[leonshaw]

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

[lts9165]

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

[xuelang]

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

[xuelang]

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

[cyberCat]

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

[xuelang]

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

[brucedone]

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

[xuelang]

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

[leonshaw]

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

[xuelang]

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

[xuelang]

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

[xuelang]

@brucedone 我们也是这个版本。。

[wtof]

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

[xuelang]

@wtof 对，这里起始不止开发，还要运维一起帮忙的。
我们就卡在运维这里，上线环境的编译系统，运维不支持高版本，虽然代码已经能编译过，但还是用老的。

我们的机器中间腾挪过，现在倒是高版本 Linux 了，支持高版本 libstdc++ 了

[nmap]

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

[clemente]

直接换 clang14

[sir283]

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