首先，要再现bug得先准备bug条件，使用Windows下的Dev-C++按照目录下bin文件夹下面的c和c++编译器和链接器，可以直接使用Dev-C++，或者用CodeBlocks然后编译链接的目录设置为Dev-C++的bin目录。这个bug是在今天月赛时候出现的，我用%lld读入一个不大的整数后，再for循环读入其它一些数字，发现无论如何输出不了，而我用cin和cout操作longlong的时候，超时1倍多，很恶心的出题人，本来就是一个水题，居然做成这样。然后没办法，快结束的时候，问旁边的队友，因为是个人赛，所以是自己在做，longlong，如何读入，他说%lld。是啊，我一直这样读，这样输出，为啥出问题了。。。没办法照着他的样子，把输入改成了int，直接%d读入，答案还是longlong，再%lld输出就没超时了，真恶心的一天啊。
64位本来就用得不多，而且对于大多数Windows下的用户，基本都是vc6和vs08什么的。vs08我已经实验过，不会出现这个bug，PS：是完全一样的代码，亲自单步调试实验的，无任何bug。vc6只能用%I64d输入和输出。那么，问题就只是在Dev-C++的用户中存在了。 回来的时候，我就决心找出问题的所在。所以，我打算升级g++的版本。下了个Dev-C++ 5.0也没用，和前面的Dev-C++ 4.9.9.2一样的，恶心啊。
然后google+百度了很久，发现CSDN上一篇博文解释说，这就是Dev-C++自己的事情。因为gcc本来是linux下的，所以longlong在自己家里是不会出现问题的。而Dev-C++是把人家移植过来的，那篇博文说Dev-C++的编译和链接器是mingw32-g++.exe，但是Mingw32在编译期间使用gcc的规则检查语法，在连接和运行时使用的却是Microsoft库。这个库里的printf和scanf函数当然不认识linux gcc下"%lld"和"%llu"，对"%I64d"和"%I64u"，它则是乐意接受的。Mingw32在编译期间使用gcc的规则检查语法，在连接和运行时使用的却是Microsoft库。这个库里的printf和scanf函数当然不认识linux gcc下"%lld"和"%llu"，对"%I64d"和"%I64u"，它则是乐意接受的。意思是，程序里面实质的二进制代码可能是微软的库，只解析%I64d,然后就可能出错了。具体是什么原因，只有开发Dev-C++的人知道了。或者其它高人。。。
#include <stdio.h>
#include <iostream>
using namespace std;
int main()
{
long long nN;
long long nX, nY;
if (scanf("%lld", &nN) != EOF)
{
printf("nN:%lld\n", nN);
for (
long long i = 0; i < nN; ++i)
{
printf("nN:%lld i:%lld\n", nN, i);
}
getchar();
printf("Over\n");
}
return 0;
}
该代码会一直死循环，大家可以试试
如果改成下面这样，还可以看到输入的数据都没有到达指定的变量
#include <stdio.h>
#include <iostream>
using namespace std;
int main()
{
long long nN;
long long nX, nY;
if (scanf("%lld", &nN) != EOF)
{
printf("nN:%lld\n", nN);
for (long long i = 0; i < nN; ++i)
{
printf("nN:%lld i:%lld\n", nN, i);
scanf("%lld %lld", &nX, &nY);
printf("nX:%lld nY:%lld\n", nX, nY);
}
getchar();
printf("Over\n");
}
return 0;
}