我认为 C++ 有很多特性把默认和非默认的情况搞反了。

比如 explicit 关键字：

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

类 A 的构造函数接受一个 int 型参数，表示 A 和 int 可以隐式转换，如果 A 是个大整数类还可以理解，否则就有点莫名奇妙了。

只有在构造函数前加上 explicit 关键字才能限制这种隐式转换：

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

大多数情况下都应该写 explicit，不写的情况是少数，所以这个关键字我认为是搞反了，应该是 implicit 才好。默认情况下不应开放隐式转换，只有用户有意开放再开放。

那应该是std::vector<bool>，或者至少应该给它换个名字。它在某些场合本身还是比较好用的，但是它严重破坏了接口语义一致性，给std::vector埋下了一个大坑，它的存在就像在本来比较有美感的STL上糊了一坨屎。

本来这玩意是标准会拿来介绍推销当时的模板偏特化的炫技产物，滑稽的是几年后标准委员会自己都认识到这是个失败透顶的设计，奈何木已成舟，这何尝不是一种行为艺术。

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)

locale，vector<bool>，filesystem，unique_ptr，iostream，fstream，抛出任意类型的异常

个人之见。

一个特性是引用，引用的本质是一个弱化后的const ptr，但问题在于它既没有办法重新赋值也没有办法做判空检查，即便从上一级传递过来一个引用表示的变量，我也没有办法完全的认为它一定是安全的。

另一个特性是模板，不可否认的模板解决了很多问题，并提供了编译期的type traits，但我始终认为编译期的type traits完全不应该基于反人类的模板元编程来搞（虽然它看起来很优雅）。

另一个模板的优势是在编译期完成求值计算，这个特性不是说不行，但是用c++写过大型工程的应该都清楚，c++和其他语言惨不忍睹的编译时间，如果再套上大量header only的库，尤其是基于template完成无法做成pch和gch的，编译时间更是达到一个令人发指的程度，所以从一开始将模板的特性功能拆开，而不是作为一个可以在编译期写个红黑树出来的元模板事实上会更加实用一些。

1、多继承。只应该单根继承，和多接口继承。

2、奇葩的数组类型，能退化成指针，但不能当返回值类型，还不能用另一个数组初始化。

3、gcc，msvc，clang希望这三家被马斯克收购，之后在暴君的命令下，砍掉两个。编译器统一，才能没这么多乱七八糟的恶心事。

const constexpr 语义不清不楚，后者完全是补丁

std::cout，委员会都觉得贵物

最贵物的是这个异常，完全没java好用，考虑的东西太多容易想不通。而且二段式构造工作中无可避免。

模板元编程。应当从一开始就搞一个正经的编译期表达式，而不是拿着模板的“匹配失败不是一个错误”到处逆练葵花宝典。