写 C++代码有感

2022-03-26 14:41:45 +08:00
 yongchiu

自写代码以来,之前一直在用 Golang 、Python 写业务代码,感觉使用起来很方便易用;最近的工作写编辑引擎,开始使用 C++写代码,还是使用的 C++17 语法,恶补 C++,感觉还是看的头大,debug 起来也很麻烦,一个单测写了两天,头文件也是各种问题,还是 Golang 好用一些啊

7406 次点击
所在节点    程序员
57 条回复
FrankHB
2022-03-27 15:46:39 +08:00
@3dwelcome std 的东西你要发呆到什么时候?
大部分 sln 根本就没鸟 MSBuild 的特性,再加上 MS 的人自己就在嫌弃( STL 迁移到 cmake ),所以实际项目很少会需要你折腾的。
大多数情况下,配好工具链直接一个 g++ *.cpp -Ixxxx 都能应付了。生成库无非需要多加点选项。
啥,你非要纠结 cl ?那只能说你活该非得盯着 VS2015 的过气货。

退一步讲,不就是个 string_view 么,自己手糊个什么难度?……抄总会吧?
github.com/FrankHB/YSLib/blob/master/YBase/include/ystdex/string_view.hpp
(只保证 C++11 能用,不对 cl 的 bug 负责。)
又不是叫你实现 is_constant_evaluated 。
说实话而且这玩意儿常见得发指,boost 里有 abseil 里有甚至 GitHub 一搜一大把,还都是 header-only 的。
你就是在找发呆的借口吧。
kkzzkk
2022-03-27 15:50:22 +08:00
每一门语言都是粗看能懂,自己写的时候才发现各种细节问题,慢慢写习惯就好了
VanityBoy
2022-03-27 16:00:12 +08:00
c++想要一周速成应该是非常难了!
FrankHB
2022-03-27 16:01:31 +08:00
@xiaotianhu 看到这里就得提一点:滥用“补全”是偷懒职业病,得治。

专业开发人员的正常工作流程就是应该熟悉实现设计需要使用哪些 API ,需要从哪里取得文档和支持。
开发工具提示 API 和文档是辅助,而不是替代。找对和正确理解文档是本分,“记忆成本”从来就是开发经验的一部分。
什么时候成了不清楚自己要调用什么东西随便输入个什么东西去补全指望蒙对了?正常不应该是理解实现方案需要花时间考虑清楚,真输入代码了顺手根本不用停,然后偶尔发现补全对了所以顺便少按键盘?

真要日常补全会显著加速的情形,无非是 API 里的标识符普遍又臭又长(比如某果家的)或者语言本身导致语法上的 boilerplate 多得要死(比如 Java ),结果换个普通点的文本编辑器就寄了。
C++是有不少废话多的地方,但不是在这个层次上,编辑器自然帮不上忙。(如果发现少补全才是槽点,大概是没能力发现最欠揍的一些地方的。)
但剩下麻烦的地方是所有用户都得被坑的。所以不挑编辑器和手速,强调用户对语用的理解,让有能力的开发者随意加速气死剩下无能狂怒的,这对专业开发者明明是优点好不……
BrettD
2022-03-27 16:16:52 +08:00
@3dwelcome 升级 Visual Studio 呗,以前的编译器怎么可能可以支持未来的 C++标准……
BrettD
2022-03-27 16:23:47 +08:00
@3dwelcome 而且 std::string_view 的旧标准 backport 库也有一堆,比如
https://github.com/bitwizeshift/string_view-standalone
https://github.com/martinmoene/string-view-lite
不升级编译器甚至也能在旧标准里面使用
FrankHB
2022-03-27 16:37:30 +08:00
@LotusChuan 习惯是习惯,但是习惯得只剩下习惯,逻辑上有时候就有点欠扁了。

(先明确大括号说的是复合语句的边界;其它情况,像 int a[] = {42};之类的情形,就算鼓吹换行的正常应该不会强迫症到强行换行。)

大括号换行的习惯大概是因为一些 IDE 的默认格式,根本是{和}的水平位置竖直方向上对齐,容易辨认。如果不换行,找起来就困难一些。
不对齐的主要理由是省空间,单独一行大括号毕竟太占地方。这个说法像++--和中缀声明符等经典 C 反人类设计一样看似有理,但仔细一想就明显双标:真想省空间,应该顺便}}}}了。

说这是 K&R 的理由应该比较充分。
注意 K&R 的风格{}换行也并不一致:函数体第一个{是换行的。因为 K&R C 函数定义中,参数的类型声明是在)和{之间,经常还需要一长串单独列出,和函数体的外层{}有必要区分,这还算能理解。
然而就是 K&R C 的函数语法,显然也不如全换行一致容易理解。奈何原作者就这样,相当多的用户入门起来也懒得多想,就有样学样咯。
更过分的是 C++和 Java 之类根本没这种语法的语言还照搬,就明显犯二了。
所以说是经典,还不如说就是教条。
K&R 的这种过气货还隔空殃及其它设计。C 函数的函数体必须是{}为边界的复合语句,这个在语义设计上是很没道理的——撑死语句就够了,不用{}这种废话。也就是因为 K&R C 的函数定义才有必要如此:如果没{,)和后面的语句之间的边界很不好分析。
结果这种设计被照抄到 C++的函数、Java/C#的方法等等一大票语言的语法中。C++“兼容”C 函数定义也就罢了,然而 C++11 的 lambda 都省不掉{}( Java 和 C#的倒是没有),这就是另一个境界的二了。

( emm ,C2x 终于要移除 K&R C 函数定义语法了,可喜可贺?)
3dwelcome
2022-03-27 16:37:51 +08:00
@BrettD 我昨晚是用的第二个 string-view-lite 项目,但还是有不少问题。

第一,改别人代码心里没底气,谁知道会不会引入什么新 bug 。
第二,用了最新语法的项目,肯定不会只用一个新特性,还用了很多 vs2015 别的不支持特性,比如一些 constexp ,别的头文件。全部改很头大。
第三,升级 vs2019 ,有些老项目代码又会报错,为老项目全部升级代码库,也很麻烦的一件事。

我就希望 cpp 编译能和 npm 一样,开箱即用,那就最好不过了。
BrettD
2022-03-27 16:42:55 +08:00
@3dwelcome 那就安装 VS2015 和 VS2019 就行了
FrankHB
2022-03-27 16:56:33 +08:00
@3dwelcome 非要死活抱着不放 VS ,那也是直接升级省事。老项目迟早得寄,趁早重写。
正常的 C++“老项目”很少会有升级语言特性导致源码层次上出问题挂的。
C++17 以来的一些自作聪明的如 char8_t 和 lambda 默认 capture 的更改让源码兼容的问题变得极其蛋疼,但那是少数。VS 这几年默认都用的 C++14 。
升级 VS2015 都会出问题,要么是在依赖旧版本 VS 专属的 bug ,要么就是代码本来就有 bug 没让 VS 发现。横竖都是代码实现质量有坑。

@BrettD 不建议玩这种魔法。VC++2015 以来的二进制兼容保证有一个理由也算是为了你少倒腾这种非主流方案。
我就有一次被逼得同时 VS2008+VS2010 一起开的经验,是因为某个欠扁的静态库依赖 VS2008 的 libcmt 。这也就是严格分离依赖的情况下才敢搞。
LotusChuan
2022-03-27 17:40:02 +08:00
@FrankHB
不理解你这大串字主要要表达什么。先介绍换行然后顺便踩一脚 C ;然后踩一脚 K&R 顺便嘲讽类 C 语言;最后加个括号表示自己知道 C2x 。

然而我一开始回复#10 只是想着让他能别太纠结换行问题。代码风格本来就是很个人的事情,方便沟通服务就行了。

所以你说的这段话对我的回复有什么意义吗。这段话拿去写自己的博客会好一点,起码在这拿来回复人我觉得没什么意义,因为都是你个人的想法输出。说直接点,就我自己写的代码,我自己写 C 缩 8 格,写 Java 缩 4 格,写 C++缩 2 格,我自己看得懂就行了。

你觉得语法不行可以去提意见让标准按你的来;觉得风格不行可以自己写 clang format 让别人按你的格式来。在这和我说一串对我回复没什么意义的话不是纯浪费时间吗。既浪费你的也浪费我的
nmap
2022-03-28 09:41:02 +08:00
你这学习路径完全是在倒退
monkeyNik
2022-03-28 12:29:35 +08:00
C 艹的问题是 模版系统+运算符重载 可以创造很多新语言。。。保证让你学了 C++基础语法也看不懂代码。这也是我比较抵触 C++的原因之一。代码是要为了实现功能同时易于维护的,而不是专门给人增加难度的。外加 boost 的一堆功能,学习曲线自己体会吧。
FrankHB
2022-03-28 15:18:12 +08:00
@LotusChuan 你确实没理解。
这表达的主要就是嘲讽类似“很个人的事情”这样的观点。
作为常识,统一这类风格的项目规范不一定是所谓“很个人的事情”;虽然姑且你也知道需要“方便沟通服务”,但后来强调“我自己写”那就又矛盾了。
说直接点,你要真局限讨论给你自己写的,那的确是所谓很个人的事情,我没兴趣评价。但实际呢?
(顺便,我倒是不反对使用不同的缩进宽度,这是很 local 的问题;一级缩进是个整体,强调一定该“等于”几个空格,反倒显得没分清一个常识:缩进是缩进,对齐是对齐,两者天然不保证可以互换。)

针锋相对地,制造误导和散布谣言(指鼓吹未经查实的所谓的优点以及仅凭个人习惯否认存在适用性差异这两方面)是公共领域问题。
之后就是通过指出对其它语言的设计的劣化来点明在这里不求甚解以个人问题为借口逃避的一些危害罢了。
我不觉得这种入门级的语用常识有单独成篇的必要,所以就是顺便一踩。有谁跳起来了我不关心;不过强行拒绝理解的话,我只能表示遗憾。

clang format 真不太够用,不过和这里无关(软硬回车和按语义换行的问题也没办法指望)。
我觉得你这里强调没理解和认为没意义的强辩确实是单方面浪费你的时间;至于我的时间,不劳您费心,况且让我多补充几段说明,客观上也有利于阐明我先前的观点。
LotusChuan
2022-03-28 15:43:54 +08:00
@FrankHB
你这段话和上一段话一样对我的回复没什么意义,说是答非所问都算不错了。让你自己找你哪句话能一一对应我哪句话都很困难吧。半句话有意义的话夹杂一大串你个人的观点输出,让我感觉我在和一个非中文母语的人沟通。如果不信的话你可以看一下你这么多回复有多少人回你呢?基本都是放任你自嗨吧,因为没多少人会浪费时间来做你的阅读理解。

我花时间回复你是想起码看看你能不能正常地说话,不过结果还是不出意料。你既做不到正常地看懂我写的字,也做不到写出让人看得懂的话。
FrankHB
2022-03-28 16:00:46 +08:00
@LotusChuan 这是公共空间的讨论。回复框边“请尽量……能够对 [别人] 有帮助”未必要包含你。重复强调对“你”没意义,才对谁更没意义。但为了让你能认识到,这个回复我先假定当作有意义。

我自忖我前面的回复全是展开的技术话题,倒是你的回复里都有断片得都出戏而莫名其妙的。所谓“拿去写自己的博客会好一点”,言下之意,个人观点不该在这发……那 OP 发这主题算啥?现在又来个“答非所问”,“问”是什么? OP 的题是“有感”,压根没问。这里就没人在问。所谓的“答”就是对回复的观点评价,是主题讨论的间接展开,也没你的评论更跑题。“不信的话……多少人回你呢”就更奇葩了,照这逻辑,你第一个提到 K&R 的回复要不是我回还就没意义了?

奉劝停止狡辩;为减少跑题影响,压缩对你多得离谱的理解偏差和显摆不理解的回复,还是得费劲。
xsen
2022-03-28 20:05:19 +08:00
@dangyuluo #28 就算是日常工作,也还是浪费生命;对老旧的语言现在真的是一点耐心都没有
若因为工作原因不得不选择某种或某几种语言作为日常使用,那为嘛不选择个没心理负担、简单、易学,自己喜欢的语言呢

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/843038

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX