| |
|
|
| 首页 淘股吧 股票涨跌实时统计 涨停板选股 股票入门 股票书籍 股票问答 分时图选股 跌停板选股 K线图选股 成交量选股 [平安银行] |
| 股市论谈 均线选股 趋势线选股 筹码理论 波浪理论 缠论 MACD指标 KDJ指标 BOLL指标 RSI指标 炒股基础知识 炒股故事 |
| 商业财经 科技知识 汽车百科 工程技术 自然科学 家居生活 设计艺术 财经视频 游戏-- |
| 天天财汇 -> 科技知识 -> 你认为 C++ 最不应该存在的特性是什么？ -> 正文阅读 |
|
|
[科技知识]你认为 C++ 最不应该存在的特性是什么？ |
| [收藏本文] 【下载本文】 |
|
你认为 C++ 最不应该存在的特性是什么？ 关注问题?写回答 [img_log] 编程 C++ C / C++ Modern C++ 你认为 C++ 最不应该存在的特性是什么？ |
|
我认为 C++ 有很多特性把默认和非默认的情况搞反了。 比如 explicit 关键字： 类 A 的构造函数接受一个 int 型参数，表示 A 和 int 可以隐式转换，如果 A 是个大整数类还可以理解，否则就有点莫名奇妙了。 只有在构造函数前加上 explicit 关键字才能限制这种隐式转换： 大多数情况下都应该写 explicit，不写的情况是少数，所以这个关键字我认为是搞反了，应该是 implicit 才好。默认情况下不应开放隐式转换，只有用户有意开放再开放。 |
|
那应该是std::vector<bool>，或者至少应该给它换个名字。它在某些场合本身还是比较好用的，但是它严重破坏了接口语义一致性，给std::vector埋下了一个大坑，它的存在就像在本来比较有美感的STL上糊了一坨屎。 本来这玩意是标准会拿来介绍推销当时的模板偏特化的炫技产物，滑稽的是几年后标准委员会自己都认识到这是个失败透顶的设计，奈何木已成舟，这何尝不是一种行为艺术。 |
|
我觉得最突兀的是面向对象风格的iostream。我倒是不觉得iostream本身不该存在，而是应该重构成和其它stl组件相同的实现方式。 Alexander Stepanov发明了泛型风格的STL，改变了C++标准库的编程风格，但是其中主要是一些容器，并不包含iostream/string，string在其它回复里面已经提到多次了，所以我就说说iostream。 iostream是用面向对象的风格实现的，而且还用到了多重继承、并且是臭名昭著的菱形继承。 |
|
|
如图可见，iostream是从istream和ostream继承的，而istream和ostream又是从ios继承而来，ios/istrream/ostream/iostream四个类形成了菱形继承，非常典型的过度设计。 另外，iostream的性能问题也是长期存在的槽点，所有刷过题的人都知道cout不如printf、cin不如scanf，并且知道sync_with_stdio这个函数，最终还形成这样一个东东： 怕有新人不知道我再啰嗦一下： ios_base::sync_with_stdio(false): 这一行代码关闭了C++标准输入输出流与C标准库输入输出流的同步。默认情况下，C++的输入输出流与C标准库的输入输出流是同步的，这意味着每当使用C++的输入输出流时，都会同步刷新C标准库的缓冲区。通过关闭同步，可以避免这种同步操作，从而提高输入输出的效率； 另外，cin.tie(nullptr): 这一行代码将C++标准输入流(cin)和C++标准输出流(cout)的绑定解除。默认情况下，cin和cout是绑定在一起的，即在执行输入操作时，输出缓冲区会自动刷新。通过解除绑定，可以避免这种自动刷新，提高输入操作的效率。 调用这个lambda并将其返回值定义为一个static，可以放在main函数之外自动运行，重用性很好。 送礼物 还没有人送礼物，鼓励一下作者吧 |
|
模板元编程。应当从一开始就搞一个正经的编译期表达式，而不是拿着模板的“匹配失败不是一个错误”到处逆练葵花宝典。 |
|
头文件。非常丑陋的东西。引入一个头文件尝尝会连锁的引入上百个头文件和上万个名字。改一个类名可能需要改数百个“前置声明”。改一个函数签名至少要改两遍。改一个头文件可能要重新编译上万个编译单元。 c++其他特质或许是褒贬不一，但头文件无疑能恶心到所有人，突出一个众生平等。 还有就是匹配失败不是错误。 |
|
垃圾回收，虽然没有编译器实现过他。。。 https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2186r2.html 送礼物 还没有人送礼物，鼓励一下作者吧 |
|
implicit conversions inherited from C (array-to-ptr, etc.) inheritance-based dynamic dispatch (i.e. virtual functions), this should be replaced by existential types (virtual concepts in C++ terminology) and unified with concepts implicit "this" that leads to duplicate const/non-const member functions (fixed in C++23 with deducing this) |
|
GC, 因为压根没人实现。 |
|
|
C++11 然后真的被移除了 |
|
|
C++23 |
|
C++ 的问题不是特性太多，而是潜规则太多。。。 |
|
TL;DR Exception, C++中不应该存在Exception。 C++有很多问题都在自于“隐式”，虽然这些功能他们确实降低了刚开始的学习成本。很多答主都或多或少提到了一些，我也挺想整理一下这个的，但是我想提另外一个特性/功能：Exception。 C++有很多可以改进的，比如变量默认可变性，比如类型隐式转换问题，比如变量拷贝不够明确的问题，但是这种问题说穿了都是小问题，通过一些简单的训练，基本上也就搞定了。也不会由于这些功能，分走大块委员会或者编译器开发者的心思，我个人认为本质上并不算大问题。 C++的Exception机制是完备的，并且深深地嵌入到了语言之中，甚至为此都破坏了很多C++祖上的设计哲学，比如对零成本抽象的坚持。显然，C++为了这套Exception机制，付出了非常非常多的成本，不管是标准制定，还是编译器实现。 C++的Exception机制真的为我们带来了众多的便利了么？我见过很多人写noexcept的烦躁，只是为了要一个干净整洁的代码库，却被迫在每个函数下写这些东西。也见过有人catch(...)的无助，鬼知道这个library到底还能throw点啥搞死caller。也见过有人在网上苦苦寻找怎么让使用了throw的C++代码通不过编译……还有那个经历了无数exception问题之后，终于在自己公司C++ style guide当中写下"We do not use C++ Exceptions. "的著名公司。 作为一个native language，特别是这么一个贴近机器，类型系统的分化远没有Java，python来的纷繁复杂的语言，我强烈认为C++中就不应该存在Exception这个特性。 |
|
vector<bool> |
|
大部分是C留下来的历史包袱 少部分是C++自己瞎搞出来的，现在还不好改，比如说explicit，iostream，vector<bool>之类的 像多继承这种还算是可以理解的，毕竟没有interface |
|
那肯定是 C++标准委员会 。 这个特性太吓人了。请问台下有哪门语言想要这个特性？想要的话，过了今晚就转给你们。 C#和Java： 我们声明，我们也是 MZ 而非 JQ 语言，我们有选票箱。 Python ：请不要粗暴干涉我们的MZ形式，我们认为各语语情不同，我们主张每一门语言的人民都有权选择与自身语情相符合的发展形式； 我们能一路爬升到榜一的位置，已经证明了我们的MZ不比任何一门语言差。 C语言： 二弟你不要过来啊！你好好发展特性，我们自然会捡着用，当然，我们肯定会有选择地捡着用。 Rust：二哥，你也别到我这里来，你的险恶用心我清楚得很。最近，我们的改革卓有成效：解散核心团队、成立 “领导委员会”，在伟大的领委会的英明领导下，我代替二哥，重娶二嫂是早晚的事。 Golang ： 去你奶奶的！谁搞的语言谁负责不就好了？老子说的“大道至简”你们就是不懂是吗？ |
|
locale，vector<bool>，filesystem，unique_ptr，iostream，fstream，抛出任意类型的异常 |
|
inline 这玩意不是指令而是对编译器的建议，编译器想采纳就采纳，不想采纳就不采纳，哪有这种道理 |
|
我觉得是多重继承。 凡是超越树的结构/结构描述。 都应该交给graph. 还有 ADL。 我感觉ADL带了很多 【隐】规则。 |
|
1、多继承。只应该单根继承，和多接口继承。 2、奇葩的数组类型，能退化成指针，但不能当返回值类型，还不能用另一个数组初始化。 3、gcc，msvc，clang希望这三家被马斯克收购，之后在暴君的命令下，砍掉两个。编译器统一，才能没这么多乱七八糟的恶心事。 |
|
std::cout，用起来是真恶心多继承delete []stl的erase、remove |
|
老生常谈, std::string并不是string. 他能写入0...... |
|
|
|
|
c++最不应该存在的就是c++自身了 c++总是在错误的决定上越走越远，怎么看都是错的，就没怎么对过 比如async/await也就是有栈纤程（stackful fiber）和无栈协程（stackless coroutine）之间做选择的时候 c++选择了微软的无栈协程的做法，不得不引入了async和await等三个关键字，并导致了染色问题 而站在对立面的就是Google，Google提议用有栈的纤程，Google已经在golang中实现了该机制 然后因为c++选择了微软的提案，直接导致Google开始质疑起c++的未来，当时就发了一系列问题吐槽，什么玩意，那么难用，还用这个提案 随后，前一段时间，Google开始鞭打c++，说，我们要从c++迁移到，java，go甚至是rust为代表的，“内存安全“的语言，它没明说是因为async/await的缘故，它说是因为内存安全，是不是跟那个原因有关，不知道，反正Google没说，但是不是有关系，不重要，结果就是，Google说，他们要迁移到java，go和rust上去 这是声明原文： https://security.googleblog.com/2024/03/secure-by-design-googles-perspective-on.html?security.googleblog.com/2024/03/secure-by-design-googles-perspective-on.html 其次是clang最重要的投资者，苹果公司 苹果公司没有明确说c++的问题，但是苹果公司在去年，不止一个公开场合，不止一个人，对外公开宣称，他们要用swift来取代c++ 苹果已经实现了在带有图形界面的应用程序这个领域，用swift 替代 objective c的目标 那现在更进一步，将要用 swift 在各个层面，来替代 c++，以及更底层一点的 c 究其原因，无论是c，c++还是objective c，其使用的编译器前端，都是clang，而swift则是另外一个前端，swiftc，因为用的都是llvm的编译器后端，所以在功能上，并不存在有什么是 clang 能做，而 swift 不能做的地方，所以苹果开始用 swift 替换 clang所支持的那些语言（c++，obj c，c），确切一点说就是用 swiftc 这个前端，替换clang 那现在问题来了，clang两个最重要的支持者，苹果和Google，都撂担子不干了，都有各自的算盘 那剩下clang你还能指望谁？ 如果没有了clang，那c++还有啥？gcc？如果当初不是gcc做得太烂，也就不会有clang和llvm了 所以指望gcc根本不靠谱 那没了gcc，还有谁？ msvc++ 那就只剩下微软自己搞了，msvc++也就只能在windows这个江河日下的平台上搞搞搞了 其他平台被牢牢拽在苹果和Google手里，跨平台？跨平台主要市场在java手里，java跨平台也主要是靠拉拢苹果，Google这些大厂来维系的，要不是Google和苹果这些大厂坚持留在jcp里面，还愿意配合的话，那java跨平台也不会这么顺畅，苹果和Google在jcp里面的各种合作态度，可比在c++标准里面所表现出来的不合作，各种争吵态度要好得多 所以c++还能指望谁？ 看来看去，也就是msvc++和windows这两个还能指望一下了，其他的平台，人家厂家都有自己的算盘，而这个算盘从已经公开的信息看，就是摆明了跟c++过不去的 就明确告诉你说，我要用swift来替代c++或者我要用java/go/rust来替代c++，就这种态度 一个没有什么大厂参与的编程语言，连各平台，各编译器都无法统一，都有各自算盘的时候 你还能指望啥？就明显是分崩离析的节奏，也难怪现在鬼佬对c++的批判开始多了起来 c++其实差不多已经完成了历史使命 剩下的，就交给swift，java这些去完成了 可能还会有点遗老，像msvc++和windows这些，那谁愿意押宝这些平台，那你自己搞去吧 这是windows市占率的图表，屡创新低，倒是安卓市占率一直在上升 苹果系列是分开统计，但是加起来基本上都是稳定在略低于四分之一酱紫 |
|
|
所以就是没啥指望 最后还是要老生重谈一下tiobe，这个肯定会有不懂事的拿出来说，去年热度上升 tiobe是热搜排行，上热搜的，不一定都是学霸，还有通缉犯 去年鬼佬因为Google，苹果，mono他爹，unity，nsa等多个领域同时爆发对于c++的争论，所以导致c++搜索热度上升，因为都在骂c++，所以c++在tiobe的热度持续上升，形成通缉犯效应，那现在随着各种证据全都指向了c++的问题之所在，业界对于c++被淘汰开始逐步形成一种共识，所以c++的热搜强度在逐步下降 还有鼓吹性能的 |
|
|
送礼物 还没有人送礼物，鼓励一下作者吧 |
|
虚继承，应该90%的人都没用过这功能吧。 |
|
子类和父类有同名成员应该直接报错，被这鬼问题坑过好几次。 在一个多人合作项目里，大家遵循相同的命名规范，继承同事写的一个类时需要翻一下这个类的族谱避免成员重名，那我宁愿不用继承了。 |
|
1.宏定义 这玩意出了之后导致很多库风格各异，看的真的是头皮发麻 2.cout cout的各种完全记不住的dec oct hex fixed setw setfill setbase setprecision setiosflags resetiosflags....噢我吐了...printf多好你非要用cout，缓冲区问题速度还没printf快 3.string char和string之间出现的种种问题是c++处理的经典烦点（不难但是就是烦）而且非常非常的繁琐（不刷几百道题经常会处理不明白） 4.多重继承 血压飙升点。不展开了 |
|
explicit ，应该默认显示 然后可以考虑加个implicit |
|
呵呵，C++的作者开发了一个以自己的姓命名的网站，在上面卖自己写的C++教程，看了其中两个，都是一千多页，教你成为C++语言专家。 你想想他要挖多少坑吧！ |
|
++ |
|
构造函数的初始化列表。我在知乎提的唯一一个问题就是吐槽这个。 放屁需要脱裤子也就罢了，穿着裤子放屁实际需要放两遍属实不能理解。 |
|
我说一个 C++ 标准之外，但与 C++ 息息相关的吧！ 那就是 C++ 编译器！拜托，我们真的不需要那么多杂七杂八的编译器，什么 MSVC、Clang、GCC、Apple Clang、Intel C++、IBM XL C++ …… 太多我就不一一列举了，编译器太多太杂，就跟当年的浏览器太多太杂一样。同一个项目源码，A能编译B报错，B能编译C报错，开发跨平台应用时适配起来简直累死人。 浏览器领域好在 chromium 最终一统江湖了，编译器领域希望也能出现一个能打的来一统江湖。目前我个人比较看好的是 LLVM，希望它能一统江湖！ 补充内容： 最好的办法就是微软放弃MSVC、GNU社区放弃GCC。这两家直接从 LLVM fork 一份，然后在 LLVM 基础上做些不痛不痒的小功能就行，核心底子都用 LLVM 的同一套代码，模式照搬微软现在 Edge 浏览器的路子。[惊喜][惊喜] |
|
：： 这到底是哪个王八蛋发明的 |
|
所有比C标准多的特性。 说实话，我真觉得有C就足够了，要快要操控底层要造轮子就用C，足矣。要高级语言那就java，Go，Python等等。C++卡中间有点不尴不尬的。 而且C跟这些高级语言都可以和谐相处，但C++不行，一般得伪装成C才能对接高级语言，何必呢，何苦呢？ |
|
|
| [收藏本文] 【下载本文】 |
| 科技知识 最新文章 |
| 百度为什么越来越垃圾了? |
| 百度为什么越来越垃圾了? |
| 为什么程序员总是发现不了自己的Bug? |
| 出现在抖音评论区里边的算命真不真？ |
| 你认为 C++ 最不应该存在的特性是什么？ |
| 为什么 Windows 的兼容性这么强大，到底用了 |
| 如何看待Nvidia禁止使用翻译工具将cuda运行 |
| 为何苹果搞了十年的汽车还是难产，小米很快 |
| 该不该和AI说谢谢? |
| 为什么突破性的技术总是最先发生在西方？ |
| 上一篇文章 下一篇文章 查看所有文章 |
|
|
|
| 股票涨跌实时统计 涨停板选股 分时图选股 跌停板选股 K线图选股 成交量选股 均线选股 趋势线选股 筹码理论 波浪理论 缠论 MACD指标 KDJ指标 BOLL指标 RSI指标 炒股基础知识 炒股故事 |
| 网站联系: qq:121756557 email:121756557@qq.com 天天财汇 |