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

C++要是有更好的包管理感觉也会好很多

啥问题，交流一下啊？

用 C++不爽的地方正是 Golang 的优势所在

c++就是浪费生命，别再入坑了。

可能是先后学造成的，我先用的 c/c++，因为那时候还没 go ，后来用 go ，一开始觉得还有点意思，写了几个后台，也不是太习惯，后来感觉还不如 PHP 来得实在。

一般来说，性能越高，代码越不好写，所以一下情况你还是得用 C++，C ，甚至汇编，因为人家就是服务这种情况的。

除了 C++ 本身的复杂外，OP 缺少底层背景应该也是一个原因。编辑引擎对性能的要求也不是特别高吧，为什么不继续用 Go 写呢？或者也可以选择 .NET 、Java 。

我写 c++没感觉出来啥问题，我有 java ，python ，js ，dart ，scala ，的底子，所以还算得心应手，就是大括号写在下一行这个特别难受，可能是写 java 写的。

建议学 RUST ，RUST 的目标是 C++的性能但更安全

没有强制要求大括号写下一行啊。。

不是我自己写的难受，是看别人代码难受，貌似大部分写 c++的人都是写在下一行

rust 黨真的是無孔不入

反 rust 黨真的是無孔不入

应该是 C 转来的习惯，毕竟 K&R 是经典。看着看着就习惯了。

以前我写 C++，一堆的异步回调，逻辑就复杂了。现在我用 golang 写，代码是顺序的，写起来就很简单，轻松加愉快

说明 rust 现在很“红”呗

Linus Torvalds: “C++ is really a terrible language!”

最近也是新学了 Golang ，感觉 golang 大概是类型安全的 c++。即使存在指针，也没有 c/c++里那种野指针的可能。

但可能与我的入门语言有关，golang 采用了像 ts 那种允许的隐式继承，同样通过扩展方法实现类的方法，对我来说也不太习惯。

只能說爭議很大

羡慕你能写 cpp

语法不熟悉，太多新语法了

估计是考虑性能吧，C++无 GC ，能够面对高并发和对实时性有要求的这种场景

golang 写的确实比较舒服，语法简单，性能也不错，语法简单也导致有些地方写的不方便

c++ 都是慢功出细活。慢慢写。 写多了就习惯了。

确实没有，不过习惯写 C++的，很多喜欢大括号在下一行，Java 入门的大括号挨着代码

我用 clang format ，默认 大括号 并不会下一行

很多时候感觉是 toolchain 没有配好。写个复杂的 cmake 或者 makefile 得花半天。程序迟迟跑不起来，没有收到正反馈，感觉沮丧。

Go 这种保姆式 toolchain ，啥都不用安装就能编译起来了。

不是特别古老的依赖的化,可以试试 vcpkg

C++可能对你是浪费生命，但对别人来说就是日常工作

之前写 PHP 好几年,开始写 Golang 觉得很麻烦,类型系统很麻烦,要多写出很多东西来.
后来生计所迫,开始写 C++, 回头再看 Golang,又感觉真的简单很多.都是对比出来的.

对比起来,我觉得 C++的一些难点:

• 编辑器和补全系统不如 Golang 那么好用,基础库又很分散,就直接导致记忆成本高.go 输入 fmt 就能自动补全 fmt 的包,C++至少我的 VIM 没有,就需要你记住 fmt 的 header 文件自己去引用.
• 语法更复杂了. 灵活性和对内存精细化控制的需求,对什么拷贝 引用 指针 左值,这些都要思考,带来更多思考负担.写其他语言不需要
• 并发编程, PHP 转 Go 的大部分都是觉得,简单的并发编程模型带来的性能提升是最爽的;然而 C++的线程+锁 的模型,说法太多了,玩不好容易悲剧.
• 调试 和 工具链,go 基本上几个命令就把周边的事儿都干了;C++的 GNU 工具链,make g++ ld gdb 每一个又都博大精深,一堆参数;一个栈溢出直接让新手无所适从,调试太麻烦也导致开发起来效率上不去.

总结,Go 或者 PHP,有 5 年开发基础的,基本上看 1 本 400 页的书就能开始干,看两本原理就能有深入的了解,干的很好了.
C++,大概你需要看:C++ Primer/Effective C++/并发编程 /STL 基础库 /模板元编程 /Linux 系统编程 /Make 教程 /gdb 教程大概才敢说我 C++入门了,可以写一些生产的项目了.....

记得有大佬说过，cpp 的设计目标是防止写代码的人失业，绝对的业界良心。

modern C++写起来还是挺舒服的

我 C++习惯写在上一行，好看多了

cpp 写起来还好…
然后比较难受的是看别人代码，有时候真的不知道这写的是啥…
然后痛不欲生的是 debug ，尤其是有模板的…
然后掉头发的，线上 core 了…内存泄露了，balabala…
然后工具链…cmake 啊 makefile 啊都特么巨难用

最近下定决心把一个古老的 vs 项目移植到了 cmake 和 vcpkg ，后悔没早一点动手，真是比直接用 sln 管理方便多了。

C++工具链是真的劝退

对于日常写 C 的人，能灵活地配置工具实现需求也是 C tool chain 的一个 feature. Tool chain 的工具很多也可以很容易做到轻量化，同其它的工具和语言整合也很灵活，就是上手比较难。

建议改行 rust

昨天下载了一个 github 源代码，硬是要 vs2019 编译，我手头只有 vs2015 ，直接傻掉，一点办法都没有。

每次新语法对老编译器都不兼容，这点真的很烦。

这点就不能学学 ts 嘛，进行源代码转译级别的向后兼容。

這個和語言本身沒關系，譬如我做 MCU 開源項目，會使用 Makefile 工程，用戶下載代碼 make 一下就可以編譯出固件。而有些人非要用 keil 、iar 等商業軟件，互不相通。。。

就是和语言有关系，项目用了 std::string_view ，这是个好东西，但是 vs2015 里没有啊。
只能看着源码发呆😳。

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 的。
你就是在找发呆的借口吧。

每一门语言都是粗看能懂，自己写的时候才发现各种细节问题，慢慢写习惯就好了

c++想要一周速成应该是非常难了！

看到这里就得提一点：滥用“补全”是偷懒职业病，得治。

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

真要日常补全会显著加速的情形，无非是 API 里的标识符普遍又臭又长（比如某果家的）或者语言本身导致语法上的 boilerplate 多得要死（比如 Java ），结果换个普通点的文本编辑器就寄了。
C++是有不少废话多的地方，但不是在这个层次上，编辑器自然帮不上忙。（如果发现少补全才是槽点，大概是没能力发现最欠揍的一些地方的。）
但剩下麻烦的地方是所有用户都得被坑的。所以不挑编辑器和手速，强调用户对语用的理解，让有能力的开发者随意加速气死剩下无能狂怒的，这对专业开发者明明是优点好不……

升级 Visual Studio 呗，以前的编译器怎么可能可以支持未来的 C++标准……

而且 std::string_view 的旧标准 backport 库也有一堆，比如
github.com/bitwizeshift/string_view-standalone
github.com/martinmoene/string-view-lite
不升级编译器甚至也能在旧标准里面使用

习惯是习惯，但是习惯得只剩下习惯，逻辑上有时候就有点欠扁了。

（先明确大括号说的是复合语句的边界；其它情况，像 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 函数定义语法了，可喜可贺？）

我昨晚是用的第二个 string-view-lite 项目，但还是有不少问题。

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

我就希望 cpp 编译能和 npm 一样，开箱即用，那就最好不过了。

那就安装 VS2015 和 VS2019 就行了

非要死活抱着不放 VS ，那也是直接升级省事。老项目迟早得寄，趁早重写。
正常的 C++“老项目”很少会有升级语言特性导致源码层次上出问题挂的。
C++17 以来的一些自作聪明的如 char8_t 和 lambda 默认 capture 的更改让源码兼容的问题变得极其蛋疼，但那是少数。VS 这几年默认都用的 C++14 。
升级 VS2015 都会出问题，要么是在依赖旧版本 VS 专属的 bug ，要么就是代码本来就有 bug 没让 VS 发现。横竖都是代码实现质量有坑。

不建议玩这种魔法。VC++2015 以来的二进制兼容保证有一个理由也算是为了你少倒腾这种非主流方案。
我就有一次被逼得同时 VS2008+VS2010 一起开的经验，是因为某个欠扁的静态库依赖 VS2008 的 libcmt 。这也就是严格分离依赖的情况下才敢搞。

不理解你这大串字主要要表达什么。先介绍换行然后顺便踩一脚 C ；然后踩一脚 K&R 顺便嘲讽类 C 语言；最后加个括号表示自己知道 C2x 。

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

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

你觉得语法不行可以去提意见让标准按你的来；觉得风格不行可以自己写 clang format 让别人按你的格式来。在这和我说一串对我回复没什么意义的话不是纯浪费时间吗。既浪费你的也浪费我的

你这学习路径完全是在倒退

C 艹的问题是 模版系统+运算符重载 可以创造很多新语言。。。保证让你学了 C++基础语法也看不懂代码。这也是我比较抵触 C++的原因之一。代码是要为了实现功能同时易于维护的，而不是专门给人增加难度的。外加 boost 的一堆功能，学习曲线自己体会吧。

你确实没理解。
这表达的主要就是嘲讽类似“很个人的事情”这样的观点。
作为常识，统一这类风格的项目规范不一定是所谓“很个人的事情”；虽然姑且你也知道需要“方便沟通服务”，但后来强调“我自己写”那就又矛盾了。
说直接点，你要真局限讨论给你自己写的，那的确是所谓很个人的事情，我没兴趣评价。但实际呢？
（顺便，我倒是不反对使用不同的缩进宽度，这是很 local 的问题；一级缩进是个整体，强调一定该“等于”几个空格，反倒显得没分清一个常识：缩进是缩进，对齐是对齐，两者天然不保证可以互换。）

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

clang format 真不太够用，不过和这里无关（软硬回车和按语义换行的问题也没办法指望）。
我觉得你这里强调没理解和认为没意义的强辩确实是单方面浪费你的时间；至于我的时间，不劳您费心，况且让我多补充几段说明，客观上也有利于阐明我先前的观点。

你这段话和上一段话一样对我的回复没什么意义，说是答非所问都算不错了。让你自己找你哪句话能一一对应我哪句话都很困难吧。半句话有意义的话夹杂一大串你个人的观点输出，让我感觉我在和一个非中文母语的人沟通。如果不信的话你可以看一下你这么多回复有多少人回你呢？基本都是放任你自嗨吧，因为没多少人会浪费时间来做你的阅读理解。

我花时间回复你是想起码看看你能不能正常地说话，不过结果还是不出意料。你既做不到正常地看懂我写的字，也做不到写出让人看得懂的话。

这是公共空间的讨论。回复框边“请尽量……能够对 [别人] 有帮助”未必要包含你。重复强调对“你”没意义，才对谁更没意义。但为了让你能认识到，这个回复我先假定当作有意义。

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

奉劝停止狡辩；为减少跑题影响，压缩对你多得离谱的理解偏差和显摆不理解的回复，还是得费劲。

＃28 就算是日常工作，也还是浪费生命；对老旧的语言现在真的是一点耐心都没有
若因为工作原因不得不选择某种或某几种语言作为日常使用，那为嘛不选择个没心理负担、简单、易学，自己喜欢的语言呢