c++最恼人的解析:

struct S
{
    S() {} //default constructor
};

int main() {

    S s(); // this is not a default construction, it declares a function named s that takes no arguments and returns S.
}

这并不是一个真正的语言特性，而是一个实现缺陷:一些早期的Fortran编译器通过使用常量池来实现常量。所有参数都是通过引用传递的。如果你调用一个函数，例如。

f(1)

编译器会将常量池中常量1的地址传递给函数。 如果您为函数中的参数赋值，则会在程序中全局地更改该值(在本例中为1)。引起了一些挠头。

下面的c#代码抛出NullReferenceException而不是打印1:

    static void SomeMethod(string format, params object[] args)
    {
        Console.WriteLine(args.Length);
    }

    static void Main(string[] args)
    {
        SomeMethod("blabla", null, "Ok here"); // print 2
        SomeMethod("blabla", null); // exception
    }

哈哈！

整个语言本身。虽然不完全是WTF的事情，但我从来没有遇到过一种语言在我的脑海中以一种刺耳的卡通声音播放。我以前也从来没有看过代码并想要惊呼“啊啊啊啊可爱!”

这个程序显示数字1-10并终止

HAI
CAN HAS STDIO?
IM IN YR LOOP UPPIN YR VAR TIL BOTHSAEM VAR AN 10
    VISIBLE SUM OF VAR AN 1
IM OUTTA YR LOOP
KTHXBYE

在c++中，“虚”MI(多重继承)允许“菱形”类层次结构“工作”，这让我觉得奇怪和讨厌。

A:基类，例如:“对象” B, C:两者都(实际上或不是)源于对象和 D:起源于B和C

问题:“正常”继承导致D是2种不明确的A。“虚拟”MI将B的A和C的A折叠为一个共享基对象A。

所以，即使你的车轮是一个对象，你的左前轮是一个车轮，你的汽车继承了四种车轮，你的汽车仍然只是一种具有虚拟MI的对象。否则，你的汽车不是一个对象，而是4个车轮对象。

这是一种奖励糟糕的类设计、惩罚编译器编写者的语言特性，并让您在运行时怀疑对象到底在哪里——以及是否有任何虚拟MI行李放错了地方。

如果在类层次结构中确实需要菱形模式，可以使用常规MI和委托给单个A基的“AProxy”来完成。

A:基类，例如:“对象” AProxy:基类，与其他A绑定的构造 B:源自A C:来源于AProxy D:源自B和C(在构造时将B的A传递给C的AProxy)

对于那些真正喜欢diamond MI的人来说，这需要做更多的工作，而我们其他人则可以安心地使用一组更易于处理的语言特性。

这让我惊艳

#define _ -F<00||--F-OO--;
int F=00,OO=00;main(){F_OO();printf("%1.3f\n",4.*-F/OO/OO);}F_OO()
{
            _-_-_-_
       _-_-_-_-_-_-_-_-_
    _-_-_-_-_-_-_-_-_-_-_-_
  _-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
  _-_-_-_-_-_-_-_-_-_-_-_-_-_
    _-_-_-_-_-_-_-_-_-_-_-_
       _-_-_-_-_-_-_-_
           _-_-_-_
}