首先，要再現(xiàn)bug得先準(zhǔn)備bug條件，使用Windows下的Dev-C++按照目錄下bin文件夾下面的c和c++編譯器和鏈接器，可以直接使用Dev-C++，或者用CodeBlocks然后編譯鏈接的目錄設(shè)置為Dev-C++的bin目錄。這個bug是在今天月賽時候出現(xiàn)的，我用%lld讀入一個不大的整數(shù)后，再for循環(huán)讀入其它一些數(shù)字，發(fā)現(xiàn)無論如何輸出不了，而我用cin和cout操作longlong的時候，超時1倍多，很惡心的出題人，本來就是一個水題，居然做成這樣。然后沒辦法，快結(jié)束的時候，問旁邊的隊友，因為是個人賽，所以是自己在做，longlong，如何讀入，他說%lld。是啊，我一直這樣讀，這樣輸出，為啥出問題了。。。沒辦法照著他的樣子，把輸入改成了int，直接%d讀入，答案還是longlong，再%lld輸出就沒超時了，真惡心的一天啊。
64位本來就用得不多，而且對于大多數(shù)Windows下的用戶，基本都是vc6和vs08什么的。vs08我已經(jīng)實驗過，不會出現(xiàn)這個bug，PS：是完全一樣的代碼，親自單步調(diào)試實驗的，無任何bug。vc6只能用%I64d輸入和輸出。那么，問題就只是在Dev-C++的用戶中存在了。 回來的時候，我就決心找出問題的所在。所以，我打算升級g++的版本。下了個Dev-C++ 5.0也沒用，和前面的Dev-C++ 4.9.9.2一樣的，惡心啊。
然后google+百度了很久，發(fā)現(xiàn)CSDN上一篇博文解釋說，這就是Dev-C++自己的事情。因為gcc本來是linux下的，所以longlong在自己家里是不會出現(xiàn)問題的。而Dev-C++是把人家移植過來的，那篇博文說Dev-C++的編譯和鏈接器是mingw32-g++.exe，但是Mingw32在編譯期間使用gcc的規(guī)則檢查語法，在連接和運行時使用的卻是Microsoft庫。這個庫里的printf和scanf函數(shù)當(dāng)然不認(rèn)識linux gcc下"%lld"和"%llu"，對"%I64d"和"%I64u"，它則是樂意接受的。Mingw32在編譯期間使用gcc的規(guī)則檢查語法，在連接和運行時使用的卻是Microsoft庫。這個庫里的printf和scanf函數(shù)當(dāng)然不認(rèn)識linux gcc下"%lld"和"%llu"，對"%I64d"和"%I64u"，它則是樂意接受的。意思是，程序里面實質(zhì)的二進制代碼可能是微軟的庫，只解析%I64d,然后就可能出錯了。具體是什么原因，只有開發(fā)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;
}
該代碼會一直死循環(huán)，大家可以試試
如果改成下面這樣，還可以看到輸入的數(shù)據(jù)都沒有到達指定的變量
#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;
}