• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            Dev-C++下使用scanf("lld", nX)讀取long long時(shí)出現(xiàn)的bug

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


            如果改成下面這樣,還可以看到輸入的數(shù)據(jù)都沒(méi)有到達(dá)指定的變量
            #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;
            }

            posted on 2011-12-11 18:20 yx 閱讀(5384) 評(píng)論(11)  編輯 收藏 引用 所屬分類: C++

            評(píng)論

            # re: Dev-C++下使用scanf("lld", nX)讀取long long時(shí)出現(xiàn)的bug 2011-12-11 18:59 泡菜

            C99里面的long longC++98里是木有的,只是大多數(shù)編譯器,擴(kuò)展支持(C++2011里正式支持),有些庫(kù)是用的宏。。。。貌似Dev-C++用的是GCC3.X的編譯器,mingw庫(kù)也比較老,干嗎不試試這個(gè)---TDM-GCC ???
            最新版本為 4.6.1,32位64位都有,它與CodeBlocks整合的很好  回復(fù)  更多評(píng)論   

            # re: Dev-C++下使用scanf("lld", nX)讀取long long時(shí)出現(xiàn)的bug 2011-12-11 19:04 泡菜

            另,提醒聲C里面的printf和scanf函數(shù)屬于不太安全的函數(shù),用的時(shí)候小心,相關(guān)資料可以參看,看雪的Oday書(shū)。。。
            好好的C++ Code干嗎用這兩個(gè)函數(shù)泥?std::cout std::endl不能解決問(wèn)題木?。。。唉!  回復(fù)  更多評(píng)論   

            # re: Dev-C++下使用scanf("lld", nX)讀取long long時(shí)出現(xiàn)的bug 2011-12-11 19:08 泡菜

            最后: GCC for Window不鏈接微軟的庫(kù),未必還鏈接其他操作系統(tǒng)的庫(kù)木?微軟的可執(zhí)行文件為PE格式,Linux是ELF格式。。。。。  回復(fù)  更多評(píng)論   

            # re: Dev-C++下使用scanf("lld", nX)讀取long long時(shí)出現(xiàn)的bug 2011-12-11 21:41 遠(yuǎn)行

            當(dāng)然是不能解決問(wèn)題,我才用這種函數(shù)的,cin和cout消耗的時(shí)間是scanf和printf的2倍不止。。。@泡菜
              回復(fù)  更多評(píng)論   

            # re: Dev-C++下使用scanf("lld", nX)讀取long long時(shí)出現(xiàn)的bug 2011-12-11 21:43 遠(yuǎn)行

            我難道不知道是PE格式,我還分析過(guò)PE寫過(guò)病毒了,微軟自己實(shí)現(xiàn)了套C和C++庫(kù),你不會(huì)不知道吧,和gcc,g++版本是不同的@泡菜
              回復(fù)  更多評(píng)論   

            # re: Dev-C++下使用scanf("lld", nX)讀取long long時(shí)出現(xiàn)的bug 2011-12-11 22:38 遠(yuǎn)行

            很不幸的是我剛按照了TDM-gcc最新版本4.61,然后用CodeBlocks關(guān)聯(lián),該問(wèn)題同樣存在,不過(guò)謝謝你推薦了這個(gè)編譯器@泡菜
              回復(fù)  更多評(píng)論   

            # re: Dev-C++下使用scanf("lld", nX)讀取long long時(shí)出現(xiàn)的bug 2011-12-12 10:20 coolypf

            @遠(yuǎn)行
            與gcc無(wú)關(guān),
            是libc的問(wèn)題(即msvcrt)
            最新的版本是支持%lld的  回復(fù)  更多評(píng)論   

            # re: Dev-C++下使用scanf("lld", nX)讀取long long時(shí)出現(xiàn)的bug 2011-12-12 13:13 泡菜

            cin和cout消耗的時(shí)間是scanf和printf的2倍不止。。。。拿你木語(yǔ)言老

            有空推薦看看,編譯器實(shí)現(xiàn)方面的書(shū),CRT的實(shí)現(xiàn)方面。。。
            在C++鑲嵌C要小心


              回復(fù)  更多評(píng)論   

            # re: Dev-C++下使用scanf("lld", nX)讀取long long時(shí)出現(xiàn)的bug 2011-12-12 15:27 遠(yuǎn)行

            是啊,所以我在文章里面的說(shuō)法是對(duì)的,鏈接庫(kù)里面實(shí)際上是微軟實(shí)現(xiàn)的@coolypf
              回復(fù)  更多評(píng)論   

            # re: Dev-C++下使用scanf("lld", nX)讀取long long時(shí)出現(xiàn)的bug 2011-12-12 15:28 遠(yuǎn)行

            c++里面也有scanf和printf,也不能說(shuō)得上鑲嵌吧@泡菜
              回復(fù)  更多評(píng)論   

            # re: Dev-C++下使用scanf("lld", nX)讀取long long時(shí)出現(xiàn)的bug 2011-12-21 12:50 ->->

            @泡菜
            這是在寫ACM代碼,沒(méi)有安全不安全可言。  回復(fù)  更多評(píng)論   

            <2011年12月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            導(dǎo)航

            統(tǒng)計(jì)

            公告

            常用鏈接

            留言簿(3)

            隨筆分類

            隨筆檔案

            me

            好友

            同學(xué)

            網(wǎng)友

            搜索

            最新評(píng)論

            閱讀排行榜

            評(píng)論排行榜

            国产亚洲精久久久久久无码77777| 一本久久综合亚洲鲁鲁五月天亚洲欧美一区二区 | 色婷婷综合久久久久中文字幕| 久久这里只有精品视频99| 亚洲伊人久久综合影院| 亚洲综合伊人久久综合| 久久夜色tv网站| 国产精品久久久久久久久久影院| 久久精品中文闷骚内射| 一极黄色视频久久网站| 国产精品美女久久久久| 99精品久久久久久久婷婷| 久久精品国产久精国产思思| 久久人人爽人人爽AV片| 久久久无码精品亚洲日韩按摩| 久久久人妻精品无码一区| 久久精品国产亚洲AV电影| 一本久久综合亚洲鲁鲁五月天| 久久精品国产一区| 青草影院天堂男人久久| 久久精品aⅴ无码中文字字幕不卡| 日本久久中文字幕| 久久亚洲精品中文字幕三区| 天堂久久天堂AV色综合| 国内精品久久人妻互换| 国色天香久久久久久久小说| 欧美激情精品久久久久久久九九九 | 韩国三级中文字幕hd久久精品| 青青青国产精品国产精品久久久久| 2021国内久久精品| 综合久久精品色| 久久一本综合| 久久久综合香蕉尹人综合网| 国产欧美一区二区久久| 国产精品久久久久天天影视| 99久久精品国产综合一区| 观看 国产综合久久久久鬼色 欧美 亚洲 一区二区 | 99精品国产在热久久| 久久久午夜精品| 日韩精品无码久久久久久| 久久久久亚洲AV成人片|