泥潭日报 uscardforum · 每日精选

两小时巨作:史上最烂的编程语言

内容摘要

C++ 语言的“史上最烂”争议:开发者对其复杂性、历史包袱和开发效率的深刻反思

该帖子围绕一个“两小时巨作:史上最烂的编程语言”的视频展开,引发了关于 C++ 语言的激烈讨论。大部分参与者认为视频对 C++ 的批评“在理”,并分享了自己在使用 C++ 过程中遇到的各种痛点,包括其复杂的语法、缓慢的标准更新、糟糕的易用性以及由此带来的开发效率低下。尽管 C++ 在某些领域(如实时性能、游戏开发)仍有优势,但其历史遗留问题和设计缺陷使其成为许多开发者“头疼”的对象。

1. 关键信息

  • C++ 的主要槽点: 复杂性高、易用性差、标准更新缓慢、API 设计奇怪、头文件问题、编译速度慢、历史包袱重、缺乏包管理器、容易导致代码风格混乱。
  • 开发者痛点:
    • 易用性: FILE* fp = std::fopen(...)std::unique_ptr<FILE, decltype(&std::fclose)> fp(...) 的对比,凸显 C++ 在资源管理上的繁琐。
    • 标准更新: SFINAE 的“脑残”设计,以及 Concepts 的想法提出多年才被纳入标准。
    • 开发效率: 视频作者和多位用户认为 C++ 的开发效率极低,甚至“负90%”。
    • 生态位: C++ 占据了许多生态位,导致在某些领域难以被替代,即使有更好的选择。
    • 入门门槛: C++ 被认为是打击新生积极性的语言,不适合作为第一门编程语言。
  • C++ 的优势(被提及但被其缺点掩盖):
    • 能够做一切事情(图灵完备)。
    • 在追求极致性能和开发效率的平衡上,仍然是许多领域的首选(如实时通信、交易、游戏开发)。
  • 其他语言的对比:
    • Rust: 被认为在内存安全方面有优势,但也有用户认为其将编译器的责任推卸给使用者。
    • Go: 被认为适合做网络服务。
    • Python: 适合做原型开发和测试,但在性能要求高的场景下存在瓶颈。
    • C: 被认为是学习计算机体系结构的基础。

2. 羊毛/优惠信息

3. 最新动态

4. 争议或不同意见

  • 对 C++ 优点的辩护:
    • 有用户认为 C++ 的易用性问题被夸大,认为可以通过配置 clang-tidy 等工具来解决。
    • 有用户认为 C++ 的复杂性是其强大功能的代价,并且“老登级”的 C++ 仍然是许多领域的必需品。
    • 有用户认为 C++ 的“品味”问题是公司文化问题,而非语言本身的问题。
  • 对 Rust 的批评:
    • 有用户认为 Rust 将编译器的责任推卸给使用者。
  • 对 Python 的批评:
    • 有用户认为 Python 在某些场景下“太慢了”,即使是 IO bound 的业务。

5. 行动建议

  • 对于 C++ 的使用者:
    • 认识到 C++ 的复杂性和历史包袱,并尝试通过自动化工具(如 clang-tidy)来规范代码风格和解决潜在问题。
    • 如果可能,考虑在新项目中使用更现代的语言或工具。
  • 对于初学者:
    • 谨慎选择第一门编程语言,避免 C++ 带来的挫败感。
    • 建议从 Python、Lisp、Java 或 C 等语言入手。
  • 对于企业:
    • 考虑在特定领域(如追求极致性能)继续使用 C++,但要意识到其开发效率的劣势。
    • 在可能的情况下,探索使用 Rust、Go 等语言来提升开发效率和安全性。
    • 建立清晰的代码规范和自动化检查流程,以缓解 C++ 代码风格混乱的问题。
原始内容
--- 第 1 楼来自 哈耶克 的回复 (2025-12-24 00:55:15 PST) ---
--- 第 2 楼来自 Fiiish 的回复 (2025-12-24 01:25:00 PST) ---

这封面怎么感觉又是rust propaganda

--- 第 3 楼来自 折木奉太郎 的回复 (2025-12-24 01:32:14 PST) ---

《讨C++檄文》

--- 第 4 楼来自 nick.gr.2019 的回复 (2025-12-24 02:43:46 PST) ---

确实在理,早该灭绝的语言了

--- 第 5 楼来自 哈耶克 的回复 (2025-12-24 09:40:18 PST) ---

还真不是,后面说了rust五分钟,其余的都是在骂c++,而且没点使用经验骂不这么犀利

--- 第 6 楼来自 gin_m 的回复 (2025-12-24 09:41:46 PST) ---

php: ?

--- 第 7 楼来自 WAIBIWAIBI 的回复 (2025-12-24 09:41:58 PST) ---

炮打c++,我的一张xxx

--- 第 8 楼来自 wilbe 的回复 (2025-12-24 15:08:48 PST) ---

一口气看完了,有理有据令人信服

--- 第 9 楼来自 waatm 的回复 (2025-12-24 16:14:10 PST) ---

看了半小时,真是爽看,没有production经验的根本做不出这视频,里面我也有一部分feature是没用过的。

上学的时候觉得c++真牛逼,因为它能做一切事情,不像其它语言专攻一个方向;工作了就觉得这个优点的代价太大了,简直积重难返。

--- 第 10 楼来自 Tachikoma 的回复 (2025-12-24 17:07:09 PST) ---

非常好的视频,使我脑袋旋转。

--- 第 11 楼来自 懵懂一时 的回复 (2025-12-24 17:18:46 PST) ---

只看了template那一段,只是一味批判SFINAE,而不知道C++20早已引入concepts(想法90年代就有了,只是没被委员会批准)

--- 第 12 楼来自 schenkerx 的回复 (2025-12-24 17:19:48 PST) ---

其实作者喷的最多的一个点是,C++总是先用奇怪的方式实现很直观的东西,然后新标准推进极其缓慢。。。

--- 第 13 楼来自 windrunner 的回复 (2025-12-24 17:20:14 PST) ---

【引用自 懵懂一时】:
想法90年代就有了,只是没被委员会批准
这还不够喷吗

--- 第 14 楼来自 jnnksn 的回复 (2025-12-24 17:20:19 PST) ---

为什么quant在用

--- 第 15 楼来自 ze3kr 的回复 (2025-12-24 17:28:07 PST) ---

IMG_5071569×415 80.4 KB

--- 第 16 楼来自 哈耶克 的回复 (2025-12-24 20:35:21 PST) ---

【引用自 waatm】:
因为它能做一切事情
只要图灵完全就可以做一切事情
【引用自 懵懂一时】:
(想法90年代就有了,只是没被委员会批准)
Exactly,一直在iso当草稿,编译器“实验性”实现,然后即使想改也改不掉了,因为太多人用

而且后面还说了Concept这个名字也挺弱智的,因为搜索引擎很容易搜错

--- 第 17 楼来自 brokencreditscore 的回复 (2025-12-25 05:49:10 PST) ---

【引用自 懵懂一时】:
而不知道C++20早已引入concepts
作者本人肯定懂Concept (他连Deduce this都知道,至少了解C++23了)。问题在于SFINAE这玩意实在是太脑残了,不骂说不过去。

--- 第 18 楼来自 YCShing 的回复 (2025-12-25 11:51:48 PST) ---

但是现在追求实时性能的话(比如real-time communication,trading,gaming),还是得用CPP吧?Python只能拿来搞prototype或者做test。

之前做research的时候为了快速搞出来基本都是写的python,现在在公司里,cpp我确实看得头疼 不过好在有AI帮忙看code,依葫芦画瓢还是能写出来自己需要的东西的

--- 第 19 楼来自 哈耶克 的回复 (2025-12-25 12:44:23 PST) ---

【引用自 YCShing】:
但是现在追求实时性能的话(比如real-time communication,trading,gaming),还是得用CPP吧?
不是,还有go/rust/c

游戏也是个特例,因为引擎历史上都是c++

但如果又要追求极致性能又要追求开发效率就没别的选择了

--- 第 20 楼来自 收束观测者 的回复 (2025-12-25 13:36:16 PST) ---

语言大战?

算我一个

Rust是个写编译器的XX把编译器的责任都推卸到使用者头上的语言

--- 第 21 楼来自 YCShing 的回复 (2025-12-25 13:36:47 PST) ---

【引用自 哈耶克】:
又要追求极致性能又要追求开发效率
对对,想了想似乎cpp在这方面还是balance一些,并且祖传代码都是cpp的话,也很难去重构了。

像我做real-time streaming的,除了cpp/python之外就没啥别的选择了。做research/testbed的时候用python,公司里做production用cpp

go的话似乎做网络挺好的,很多大厂涉及networking的后端就有用go吧,我知道有一些学术圈/工业界research组也有用go

rust确实挺不错的,最近参与的一个开源项目(也是和real-time streaming相关)直接选择从零开始用rust而不是cpp,但是想说服公司的人用rust还是有难度

c的话就太不方便了(

--- 第 22 楼来自 哈耶克 的回复 (2025-12-25 13:39:45 PST) ---

【引用自 收束观测者】:
Rust是个写编译器的XX把编译器的责任都推卸到使用者头上的语言
看到过一个有意思的说法,rustc就像irs,虽然它知道该怎么做是对的,但还是要你自己再搞一遍

--- 第 23 楼来自 争取多活两年 的回复 (2025-12-25 13:46:58 PST) ---

本老刚入行就发现CPP是个垃圾语言了。

其实编程语言和产品一样,CPP就是的产品经理那个水平做出来的。

--- 第 24 楼来自 收束观测者 的回复 (2025-12-25 13:47:22 PST) ---

所以拿着rust dis C++的内存安全性也就罢了

拿着Rust dis C++易用性的我只能表示满脸问号

C++喷点其实主要也就是易用性和安全性两个点上

这俩个问题本质是因为

C++功能太强了,用户可以轻易做到几乎任何想做的事情(斜眼看rust)但是flexibility的极致导致的是非pro用户无所适从,使用门槛太高
历史包袱太重,前向兼容legacy semantics 积重难返

要我说C++就该做减法,新标准里出个subset只支持modernized semantics,多塞点语法糖

再把hardline无政府主义丢一丢,搞个包管理器把de factor标准库都收编收编,立马焕然一新了

rust和go吹牛逼的内存安全性C++可以很容易通过砍legacy语法来实现。甚至基于现有tooling用clang-tidy限制项目里允许使用的语法外加编译器正确配置参数可以解决绝大部分内存安全性问题

--- 第 25 楼来自 哈耶克 的回复 (2025-12-25 14:12:59 PST) ---

【引用自 收束观测者】:
拿着Rust dis C++易用性的我只能表示满脸问号
C++和Go一样,奖励喜欢偷手的程序员

打开文件:
FILE* fp = std::fopen("wulifen.in", "r");

std::unique_ptr<FILE, decltype(&std::fclose)> fp(std::fopen("wilifen.in", "r"), &std::fclose);
【引用自 收束观测者】:
rust和go吹牛逼的内存安全性C++可以很容易通过砍legacy语法来实现
这辈子估计都不会发生,C++为了狗操的后向兼容可以做出任何事情
【引用自 收束观测者】:
C++功能太强了,用户可以轻易做到几乎任何想做的事情
为了0.1%的用户什么都要实现一下,最后变成了洗碗池

image728×714 48.6 KB

--- 第 26 楼来自 Nokuno 的回复 (2025-12-25 14:17:39 PST) ---

可控!快!

--- 第 27 楼来自 收束观测者 的回复 (2025-12-25 14:23:22 PST) ---

【引用自 哈耶克】:
C++和Go一样,奖励喜欢偷手的程序员
打开文件:
FILE* fp = std::fopen("wulifen.in", "r");
std::unique_ptr<FILE, decltype(&std::fclose)> fp(std::fopen("wilifen.in", "r"), &std::fclose);
这种不是典型的语法糖发少了嘛

现在有coding agent了这种都自动补全搞定了吧
【引用自 收束观测者】:
rust和go吹牛逼的内存安全性C++可以很容易通过砍legacy语法来实现
【引用自 哈耶克】:
这辈子估计都不会发生,C++为了狗操的后向兼容可以做出任何事情
自己project上用clang-tidy配就完了

C++说白了门槛最高的地方在配环境,开发环境编译环境CI环境

我估计喷C++的人十个有九个有过被配环境折磨到最后都没有figure out的经历

--- 第 28 楼来自 jnnksn 的回复 (2025-12-25 15:06:34 PST) ---

rust宇宙第一

--- 第 29 楼来自 Piaji 的回复 (2025-12-25 16:16:41 PST) ---

看了小20分钟,喷的很在理

就这老登级东西居然是大学学的第一门编程语言,极大地打击新生的积极性

公司里的话说实话选择不是那么多,因为C艹已经占据了很多生态位。问题在于这么多年过去了,C艹还解决不了易用问题,反而变得更复杂

我觉得AI会极大增加以后C艹代码库的复杂性。现在已经没人去看 cpprefernce 或者了解 cpp best practice了,都是问AI,关键AI学得最多的还是垃圾代码,这下只会造成代码垃圾程度的指数级增长

如果C艹可以规范出一套东西语法,把奇淫技巧留给高手,还是很有价值的。毕竟大部分时候都是写语法,偏偏这时C艹最灾难的地方。

--- 第 30 楼来自 哈耶克 的回复 (2025-12-25 16:21:13 PST) ---

【引用自 Piaji】:
就这老登级东西居然是大学学的第一门编程语言,极大地打击新生的积极性
俺们学校三门入门课

Python+Lisp

Java

C+RISCV asm

彻底放弃狗操的C++,良苦用心啊
【引用自 收束观测者】:
自己project
就不用C++了

--- 第 31 楼来自 收束观测者 的回复 (2025-12-25 16:28:48 PST) ---

【引用自 哈耶克】:
入门课
以前不都是C吗

我觉得C++至少应该是三字头四字头的课

--- 第 32 楼来自 msft 的回复 (2025-12-25 16:31:43 PST) ---

【引用自 Piaji】:
因为C艹已经占据了很多生态位
确实。想用个python,第一个问题是一些内部dependency没有python api你咋整,第二问题是python “太慢了” - 总有人跟你说python太慢了,即便整个业务完全io bound

--- 第 33 楼来自 Piaji 的回复 (2025-12-25 16:31:59 PST) ---

我的大学CS学院第一门是C,接下来学cpp。别的工学院第一门cpp

不过说实话大学学的那点东西,c/cpp没啥区别,都应该从入门课中剔除

--- 第 34 楼来自 Piaji 的回复 (2025-12-25 16:33:00 PST) ---

经典太慢了

--- 第 35 楼来自 收束观测者 的回复 (2025-12-25 16:34:56 PST) ---

【引用自 msft】:
总有人跟你说python太慢了,即便整个业务完全io bound
python太慢了

真的太慢了

慢到了俺们的项目里python busy loop提交系统调用都没法把物理bandwidth占满的地步

竞争对手最后都是把critical path用rust / C++写了再用python调,估计俺们也逃不掉这一遭
【引用自 Piaji】:
c/cpp没啥区别,都应该从入门课中剔除
不学C意味着计算机体系构架也不用学了

以后CS学院全都改名叫CRUD技校好了

--- 第 36 楼来自 Edward40 的回复 (2025-12-25 16:36:55 PST) ---

没点进来就知道是什么

--- 第 37 楼来自 哈耶克 的回复 (2025-12-25 16:38:33 PST) ---

【引用自 msft】:
第一个问题是一些内部dependency没有python api你咋整,第二问题是python “太慢了”
我老公司的办法是雇一个团队维护c++ → python api
【引用自 msft】:
总有人跟你说python太慢了
确实慢,但并不需要速度但是觉得python慢所以不写的跟风狗也确实多

python我经常遇到的问题其实和c++也差不多,有人喜欢偷手,最后就会写出来一坨屎
【引用自 Piaji】:
c/cpp没啥区别,都应该从入门课中剔除
os/systems还是要学点C的,毕竟本质portable assembly

--- 第 38 楼来自 Piaji 的回复 (2025-12-25 16:50:29 PST) ---

【引用自 哈耶克】:
os/systems还是要学点C
【引用自 收束观测者】:
不学C意味着计算机体系构架也不用学了
我们大学第一门课就学c,然而os/计算机体系架构这些课程都是大三才学的。

我的看法是编程语言是工具,先从简单的学起好一点,然后再学原理。当时学C的时候作业也就是写逻辑,并不需要理解os。可能当时我太菜了真的没学明白

--- 第 39 楼来自 争取多活两年 的回复 (2025-12-25 16:51:29 PST) ---

本老最烦用C++的码农了,毫无品味。

--- 第 40 楼来自 aia 的回复 (2025-12-25 16:53:13 PST) ---

两小时的檄文,标记一下晚上看看

--- 第 41 楼来自 哈耶克 的回复 (2025-12-25 16:53:28 PST) ---

【引用自 Piaji】:
我们大学第一门课就学c
不能不学,但没那么低抽象层的科目,也没必要用C

不是不学C,是缓学慢学,有节奏的学,让有准备的人先学,让有能力的人先学,才能先学带动后学,也要具体情况具体学,不是盲目学,而是高效学,精准学,科学学,有策略的学,让懂C++的人参与学,让善沟通的人带头学,同时兼顾特殊情况,灵活学。

--- 第 42 楼来自 争取多活两年 的回复 (2025-12-25 16:54:17 PST) ---

学C很容易把人整出来PTSD这辈子都不喜欢编程了。

--- 第 43 楼来自 Piaji 的回复 (2025-12-25 16:55:37 PST) ---

你最好是在说C
【引用自 争取多活两年】:
整出来PTSD
楼上就疯了一个

--- 第 44 楼来自 哈耶克 的回复 (2025-12-25 16:58:48 PST) ---

【引用自 争取多活两年】:
学C很容易把人整出来PTSD这辈子都不喜欢编程了。
学C可以熟悉内存管理,我觉得很锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯

Segmentation Fault (core dumped)

--- 第 45 楼来自 争取多活两年 的回复 (2025-12-25 16:59:27 PST) ---

烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫烫

--- 第 46 楼来自 收束观测者 的回复 (2025-12-25 16:59:41 PST) ---

【引用自 Piaji】:
先从简单的学起好一点,然后再学原理。当时学C的时候作业也就是写逻辑,并不需要理解os。可能当时我太菜了真的没学明白
两种教学思路

一种是甭管懂不懂先背心法总纲,让你先死记硬背背牢了,然后花几年时间练招的过程里慢慢体悟

另一种是不教心法上来直接练招数,练一大堆差不多了再开始学心法

第一种当然比较痛苦,但是我觉得最终效果比第二种好

--- 第 47 楼来自 争取多活两年 的回复 (2025-12-25 17:00:31 PST) ---

收老师一看就是第一种教出来的。你教CD也是这个风格。

--- 第 48 楼来自 收束观测者 的回复 (2025-12-25 17:00:55 PST) ---

我是转行的。没机会第一种

C我是研究生才(正经)学的

--- 第 49 楼来自 哈耶克 的回复 (2025-12-25 17:01:48 PST) ---

【引用自 收束观测者】:
另一种是不教心法上来直接练招数,练一大堆差不多了再开始学心法
这也是为啥算法竞赛出身的刚进学校写代码普遍写得都是狗屎

--- 第 50 楼来自 uscard1024 的回复 (2025-12-25 17:06:01 PST) ---

居然还有人以为C艹只是门编程语言

--- 第 51 楼来自 gbus 的回复 (2025-12-25 17:43:21 PST) ---

进来前就知道是哪个视频了

谁踩cpp我支持谁。史上最的语言,开发效率直接 -90%,我真怀疑省的那点GCU和电费够不够付因为用 CPP 多出来的人力花费。一个编程语言是怎么做到让开发者写每一行代码都要考虑是不是 best practice,是否符合reviewer的品味,以及是不是有未知的 side effect 的。

--- 第 52 楼来自 收束观测者 的回复 (2025-12-25 18:01:56 PST) ---

【引用自 gbus】:
每一行代码都要考虑是不是 best practice,是否符合reviewer的品味
有没有可能这不是语言问题而是贵 的文化问题

--- 第 53 楼来自 gbus 的回复 (2025-12-25 18:20:40 PST) ---

有没有可能这个文化是被 Cpp 逼出来的,用 Cpp 写的开源项目我都不敢看,风格各异还好说,还偶尔有看不懂的写法蹦出来,还不是 Cpp Committee 往里面狂塞垃圾导致的,这要是出现在内部代码库,开发效率再减 10%

--- 第 54 楼来自 收束观测者 的回复 (2025-12-25 18:22:34 PST) ---

【引用自 gbus】:
有没有可能这个文化是被 Cpp 逼出来的
有没有可能C艹只是给了贵毒文化更大的发挥空间

别家就没这些破事

不管茴字写法是四种还是四十种,逼着人用自己那种方法写的肯定不是茴这个字的问题啊

--- 第 55 楼来自 KDI 的回复 (2025-12-25 18:24:34 PST) ---

没学过C和Cpp的真的不能领会到编程的魅力

--- 第 56 楼来自 gbus 的回复 (2025-12-25 18:31:08 PST) ---

有没有可能没破事是因为品味比 还低。 自创的语言品味都很低,在Cpp规范这件事上我倒是从质疑到理解。但是 在这个语言上doubledown和它双向奔赴我只能举双脚反对了

--- 第 57 楼来自 收束观测者 的回复 (2025-12-25 18:35:28 PST) ---

【引用自 gbus】:
有没有可能没破事是因为品味比 还低
所以你到底是想要编程语言实用还是想要有
【引用自 gbus】:
品味

--- 第 58 楼来自 austurela 的回复 (2025-12-25 18:38:43 PST) ---

c++是很烂我觉得,我们公司爱写的人都是因为路径依赖且不会别的语言

--- 第 59 楼来自 gbus 的回复 (2025-12-25 18:45:38 PST) ---

这两个冲突吗,就是为了实用才强制规范(品味)。一个东西一个组十二个人能写出十二种风格,那还开发个嘚,直接删库跑路了。强制规范 =》增加心理负担,不强制规范 =〉极大增加开发负担,归根到底不还是这个语言的问题?

--- 第 60 楼来自 收束观测者 的回复 (2025-12-25 19:16:12 PST) ---

【引用自 gbus】:
强制规范
直接clang-tidy进CI检查就完了

正经公司写python一样有pyright给你立各种规矩的

贵又要搞品味又不用自动化工具规范而在review里人肉检查说到底就是
【引用自 gbus】:
reviewer
想在这个过程里找存在感的独家文化

--- 第 61 楼来自 gbus 的回复 (2025-12-25 19:20:50 PST) ---

怎么可能没有自动化工具规范,cpp 是这个就能拯救的吗?如果这个语言烂是只在语法层面,能少99%的黑子

--- 第 62 楼来自 收束观测者 的回复 (2025-12-25 19:28:56 PST) ---

你能想到的
【引用自 gbus】:
风格
clang-tidy都能解决

我与阁下素昧平生阁下一开口喷我就知道是家还不说明问题嘛

--- 第 63 楼来自 gbus 的回复 (2025-12-25 19:36:29 PST) ---

每一个CL都有clang-tidy的,谢谢,而且还有额外的AI reviewer,这并不能解决cpp的问题。你的喷点很奇怪,我喷cpp烂,你喷 烂,这两者的关联好像并不是那么多,我不想在 写cpp,更不想在任何其他公司写cpp(管中窥豹那些开源项目),这个问题的根源出在 cpp committee,为什么其他语言都没这个问题。

我投降了,停止讨论,不然快进到吵架版了

--- 第 64 楼来自 dhallo 的回复 (2025-12-25 19:49:33 PST) ---

问题是用谁替代 那么多python底层cpp的包 难道让人家转到rust吗 感觉太费力了

--- 第 65 楼来自 Baba 的回复 (2025-12-25 19:54:41 PST) ---

刚写完C++打开论坛看到这么个帖子系列。。。。

--- 第 66 楼来自 DCVSMARVEL 的回复 (2025-12-25 20:00:36 PST) ---

致敬传奇耐喷王cpp

--- 第 67 楼来自 哈耶克 的回复 (2025-12-25 20:08:02 PST) ---

【引用自 收束观测者】:
clang-tidy都能解决
C++没有pep8,最后还是各自听各自的,更别说c++的静态分析能力也很糟糕
【引用自 gbus】:
为什么其他语言都没这个问题
C++是90年代百家齐放的老登产物,只有标准没有实现,要加个东西得20个公司400iq领退休金的大爷大妈飞到瑞士的五星级酒店讨论10年,最后写一个114514页长的标准,100000页里的功能只有1.14%用户用到

Ruby和Python都有仁慈独裁者一锤定音;Rust有implementation first

--- 第 68 楼来自 收束观测者 的回复 (2025-12-25 20:15:26 PST) ---

【引用自 哈耶克】:
C++没有pep8
问题clang-tidy里你可以自定义要什么不要什么,clang-format又可以cover所有cosmetic的问题

所以一个well-setup C++ project不存在说统一写法/风格/品味的问题,觉得SFINE难读难维护直接在clang-tidy设置里全部干掉就完了

当然这个well-setup是个相当高的门槛
【引用自 哈耶克】:
Ruby和Python都有仁慈独裁者一锤定音
这条路走到底就是“我是你爹”的golang连花括号不准放在下一行都直接build进compiler

golang这种玩意儿拿来流水线训练生产CRUD kid当然是很有效率的,不管从企业管理还是软件工程角度都是坠现代化坠吼的

但是有ego的码农不可能喜欢这种东西

--- 第 69 楼来自 brokencreditscore 的回复 (2025-12-25 22:22:59 PST) ---

Rust是资本家的语言,C++才属于程序员

--- 第 70 楼来自 Americanbigbull 的回复 (2025-12-25 22:33:21 PST) ---

看领域,我做应用数学只能用c艹

另外怪不得我简历总是第一步就被刷了原来c艹没品位

--- 第 71 楼来自 otonoco 的回复 (2025-12-26 01:04:23 PST) ---

@用rust重写

--- 第 72 楼来自 Humphrey 的回复 (2025-12-26 06:57:38 PST) ---

本来想说用屎山论可以解读,但是看完视频又觉得C++这个项目从day1就是这样了

--- 第 73 楼来自 何思远 的回复 (2025-12-28 11:32:32 PST) ---

在厂里写过好些年的生产C++ 代码的我真的对这个视频深有共鸣,并且在厂里写代码已经把 Build System, Compiler, Package Manager这些都确定下来了, 比如用Bazel + monorepo就不用考虑怎么引用代码的问题,引用第3方的代码,直接把源码放进代码仓库等等。

但是还是会视频有提到的无法解决的,比如STL 库的坑,头文件, 编译速度,奇怪的API 设计。

比如 C++11 加了 smart pointer 之后,就有一个 make_shared 来创建一个 shared_ptr, 但是对于 unique_ptr, 又没有对应的 make_unique, 要不就自己写一个, 要不就等 C++14(C++14他们又把这个给加上,真的是之前忘了)

从业多年,写过不同语言的生产代码之后, 我对C++ 的感觉真的是从原来的热爱,研究各种语言特性,到现在逐渐无感,除非是给厂里打螺丝,不然是不会用C++写自己的个人项目的,引入第三方依赖就麻烦死了。

(之前不懂为什么写C++的人这么喜欢重复造轮子,他们说自己喜欢定制的「小而美」,还经常吐槽Java的人喜欢大而全的框架,后来才理解,因为C++要引用别人的库非常痛苦,可能自己再造一个轮子来得更容易)

有人问我,C++ 是不是很强大?我会回答: 是的,绝对强大。

但是我受不了的是各种似乎只写过C++的人把C++的各种缺点,各种问题都说成是多么高瞻远瞩的了不起设计一样。事实上,不读5本关于C++的经典著作,不了解各种坑是没法开写的,不然可能上手就炸。

提起C++问题,就说C++ 委员会已经解决了/正在解决中,你看xx提案不是已经通过了嘛, 在c++3x 可能就会出来了。比如C++20 提出来的 module, 连std library 自己都不支持,别人怎么用. C++20 到2030年有人开始用都算快的了.

坦白说,C++ 就是是个充满着各种历史问题,又不得不用的语言。

最后引用一下作者的话:

If you love C++, it means you don’t know C++ much – me

--- 第 74 楼来自 YCShing 的回复 (2026-03-08 13:27:36 PDT) ---

【引用自 何思远】:
比如 C++11 加了 smart pointer 之后,就有一个 make_shared 来创建一个 shared_ptr, 但是对于 unique_ptr, 又没有对应的 make_unique, 要不就自己写一个, 要不就等 C++14(C++14他们又把这个给加上,真的是之前忘了)
靠这个我太有体会了