万年历 购物 网址 日历 小说 | 三峰软件 天天财富 小游戏 视频推荐 小游戏
TxT小说阅读器
↓小说语音阅读,小说下载↓ 		一键清除系统垃圾
↓轻轻一点,清除系统垃圾↓ 		图片批量下载器
↓批量下载图片,美女图库↓ 		图片自动播放器
↓图片自动播放,产品展示↓
首页  日历2024  日历2025  日历2026  日历知识  | 每日头条  视频推荐  数码知识 两性话题 情感天地 心理咨询 旅游天地 | 明星娱乐 电视剧  职场天地  体育  娱乐 
日历软件  煮酒论史  历史 中国历史 世界历史 春秋战国 三国 唐朝 宋朝 明朝 清朝 哲学 厚黑学 心理学 | 文库大全  文库分类 
电影票房 娱乐圈 娱乐 弱智 火研 中华城市 仙家 六爻 佛门 风水 钓鱼 双色球 戒色 航空母舰 网球 乒乓球 足球 nba 象棋 体操
商业财经知识 科技 汽车知识 工程技术知识 时尚与穿搭 家居与生活 设计艺术知识
    
  知识库 -> 科技 -> 你认为 C++ 最不应该存在的特性是什么？ -> 正文阅读

[科技]你认为 C++ 最不应该存在的特性是什么？

[收藏本文] 【下载本文】
你认为 C++ 最不应该存在的特性是什么？
关注问题?写回答
[img_log]
[img_log]
编程
C++
C / C++
Modern C++
你认为 C++ 最不应该存在的特性是什么？
那应该是std::vector<bool>，或者至少应该给它换个名字。它在某些场合本身还是比较好用的，但是它严重破坏了接口语义一致性，给std::vector埋下了一个大坑，它的存在就像在本来比较有美感的STL上糊了一坨屎。
本来这玩意是标准会拿来介绍推销当时的模板偏特化的炫技产物，滑稽的是几年后标准委员会自己都认识到这是个失败透顶的设计，奈何木已成舟，这何尝不是一种行为艺术。
我认为 C++ 有很多特性把默认和非默认的情况搞反了。
比如 explicit 关键字：

struct A
{
    A(int);   // Bad
};

类 A 的构造函数接受一个 int 型参数，表示 A 和 int 可以隐式转换，如果 A 是个大整数类还可以理解，否则就有点莫名奇妙了。
只有在构造函数前加上 explicit 关键字才能限制这种隐式转换：

struct A
{
    explicit A(int);   // Good
};

大多数情况下都应该写 explicit，不写的情况是少数，所以这个关键字我认为是搞反了，应该是 implicit 才好。默认情况下不应开放隐式转换，只有用户有意开放再开放。
三大编译器互不兼容，还绑定五大操作系统，形成生态孤岛，是最令人抓狂的。
MSVC：夹带微软语法私货，采用微软独家 ABI。仅用于 Windows。GCC：夹带 GNU 语法私货，采用 Itanium C++ ABI。主要用于 Linux，偶尔用于 Windows，但几乎不再用于 MacOS 和 iOS。Clang：主要用于 MacOS、iOS、Android。虽然它声称兼容前两个编译器的语法扩展和 ABI，可作为跨平台折中选择，但并非完美兼容，有时还存在问题。
还有其他编译器我就不列举了。
各个编译器对 C/C++ 特性的支持程度参差不齐。并且 MSVC 是专业的 C++ 编译器，所以故意阉割 C 语言标准的实现。很多开源项目只好使用复杂的预处理指令，为不同平台和编译器分别编写代码。
最智障的是，某些开源软件是通过识别当前系统来假设我使用的编译器的，伪代码如下：

#ifdef __linux__
#include <gcc/header.h>
#endif

#ifdef _WIN32
#include <msvc/header.h>
#endif

#ifdef __APPLE__
#include <clang/header.h>
#endif

我亲测在 Windows 下用 GCC 编译一些开源项目时会报错，因为它们一旦察觉出我当前系统是 Windows，就断定我在用 MSVC，试图启用 MSVC 的头文件和语法扩展，然后报错。
本来说好的 C/C++“一次编写、到处编译”的源码级跨平台性呢？我就非得在不同平台下使用不同的编译器吗？
我承认这是历史遗留问题，没办法的，现在正在探索 Rust 等其他语言。
我觉得最突兀的是面向对象风格的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这个函数，最终还形成这样一个东东：

static int speedup=[](){
	ios_base::sync_with_stdio(false);
	cin.tie(nullptr);
	return 0;
}();

怕有新人不知道我再啰嗦一下：
ios_base::sync_with_stdio(false): 这一行代码关闭了C++标准输入输出流与C标准库输入输出流的同步。默认情况下，C++的输入输出流与C标准库的输入输出流是同步的，这意味着每当使用C++的输入输出流时，都会同步刷新C标准库的缓冲区。通过关闭同步，可以避免这种同步操作，从而提高输入输出的效率；
另外，cin.tie(nullptr): 这一行代码将C++标准输入流(cin)和C++标准输出流(cout)的绑定解除。默认情况下，cin和cout是绑定在一起的，即在执行输入操作时，输出缓冲区会自动刷新。通过解除绑定，可以避免这种自动刷新，提高输入操作的效率。
调用这个lambda并将其返回值定义为一个static，可以放在main函数之外自动运行，重用性很好。
送礼物
还没有人送礼物，鼓励一下作者吧
模板元编程。应当从一开始就搞一个正经的编译期表达式，而不是拿着模板的“匹配失败不是一个错误”到处逆练葵花宝典。
[收藏本文] 【下载本文】
   科技 最新文章
站在 2025 年年末，你认为 AI 究竟是真革命
你认为 C++ 最不应该存在的特性是什么？
如何看待小红书上的新?厨房辩论？
为何小米和雷军突然之间口碑翻转了？
微信朋友圈要凉了吗？
为什么 LLM 仅预测下一词，就能「涌现」出高
百度为什么越来越垃圾了?
为什么 LLM 仅预测下一词，就能「涌现」出高
为什么 LLM 仅预测下一词，就能「涌现」出高
站在 2025 年年末，你认为 AI 究竟是真革命
上一篇文章           查看所有文章
加:2025-12-30 10:19:43  更:2025-12-30 10:26:33 
 
娱乐生活: 电影票房 娱乐圈 娱乐 弱智 火研 中华城市 印度 仙家 六爻 佛门 风水 古钱币交流专用 钓鱼 双色球 航空母舰 网球 乒乓球 中国女排 足球 nba 中超 跑步 象棋 体操 戒色 上海男科 80后
足球: 曼城 利物浦队 托特纳姆热刺 皇家马德里 尤文图斯 罗马 拉齐奥 米兰 里昂 巴黎圣日尔曼 曼联
  网站联系: qq:121756557 email:121756557@qq.com  知识库