在你看来,你遇到过的最令人惊讶、最怪异、最奇怪或最“WTF”的语言特性是什么?
请每个回答只回答一个特征。
在你看来,你遇到过的最令人惊讶、最怪异、最奇怪或最“WTF”的语言特性是什么?
请每个回答只回答一个特征。
当前回答
在Python中:
>>> x = 4
>>> y = 1000000
>>> x is 4
True
>>> y is 1000000
False
>>>
如果你不相信,就试试吧!
其他回答
在Python中:
i = 1
++i
print i
输出“1”。行'++i'的计算结果为+(+i) (Python不支持增量操作符)
在fortran中(当然是77,可能在95中也是如此),未声明的变量和以I到N开头的参数(“In”组)将是INTEGER,所有其他未声明的变量和参数将是REAL(源)。这与“在某些情况下可选的空白”相结合,导致了最著名的错误之一。
正如弗雷德·韦伯在1990年的《另类民间传说:计算机》一书中所说:
I worked at Nasa during the summer of 1963. The group I was working in was doing preliminary work on the Mission Control Center computer systems and programs. My office mate had the job of testing out an orbit computation program which had been used during the Mercury flights. Running some test data with known answers through it, he was getting answers that were close, but not accurate enough. So, he started looking for numerical problems in the algorithm, checking to make sure his tests data was really correct, etc. After a couple of weeks with no results, he came across a DO statement, in the form: DO 10 I=1.10 This statement was interpreted by the compiler (correctly) as: DO10I = 1.10 The programmer had clearly intended: DO 10 I = 1, 10 After changing the . to a , the program results were correct to the desired accuracy. Apparently, the program's answers had been "good enough" for the sub-orbital Mercury flights, so no one suspected a bug until they tried to get greater accuracy, in anticipation of later orbital and moon flights. As far as I know, this particular bug was never blamed for any actual failure of a space flight, but the other details here seem close enough that I'm sure this incident is the source of the DO story.
我认为这是一个很大的WTF,如果DO10I被作为DO10I,并且反过来,因为隐式声明被认为是类型REAL。这是个很棒的故事。
C的多个名称空间:
typedef int i;
void foo()
{
struct i {i i;} i;
i: i.i = 3;
printf( "%i\n", i.i);
}
或与字符:
typedef char c;
void foo()
{
struct c {c c;} c;
c: c.c = 'c';
printf( "%c\n", c.c);
}
在我看来,这在c++中是不允许的:
class A {
public:
virtual string foo(){return "A::foo";}
};
class B : public A {
public:
virtual string foo(){return "B::foo";}
};
int main () {
B* b = new B();
// In my opinion the following should not be allowed
cout << b->A::foo() << endl; // Will print "A::foo"
}
这似乎是正确的,但这意味着如果不允许子类的用户调用原始方法而不是新方法,就不能重写方法。
只要考虑一个集合的子类,当向集合本身添加一个元素时,您希望增加元素的数量。
一个合乎逻辑的解决方案是重写add()方法,在添加元素之前增加计数器,但是新集合的用户可以使用旧方法向其添加元素,这样就绕过了增量,导致元素计数器与集合的实际元素数量不一致。
这在Java中是不可能的。
Algol通过名称传递(使用C语法说明):
int a[3] = { 1, 2, 3 };
int i = 1;
void f(int j)
{
int k;
k = j; // k = 2
i = 0;
k = j; // k = 1 (!?!)
}
int main()
{
f(a[i]);
}