• <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>

            This blog has been shut down permanently.

              C++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
              13 隨筆 :: 0 文章 :: 25 評論 :: 0 Trackbacks

            1.輸入輸出

            ACM和TopCoder不同,TopCoder只用讓參賽者寫一個(gè)class,而ACM需要參賽者完成整個(gè)console程序.在TopCoder中,輸入輸出是通過parameter傳遞的,不用過多考慮,在ACM中,卻需要自己編寫.

            (1).只有一組輸入時(shí),這種情況不用我說了,都會(huì),但是通常也不會(huì)有這么水的題

            (2).固定組數(shù)的輸入,可以利用一個(gè)計(jì)數(shù)器和while語句完成,

            01 #include <iostream>
            02
            03 int main(void){
            04     int n;
            05     scanf("%d", &n);
            06     while (n--){
            07         //...
            08     }
            09     //...
            10     return 0;
            11 }

            (3).測試數(shù)據(jù)結(jié)尾有標(biāo)志字符(例如最后一組輸入后給一個(gè)0),這個(gè)只用加一個(gè)if語句判斷讀入的數(shù)據(jù)是什么,是結(jié)束標(biāo)志跳出就ok了.也不多說了

            (4).題目沒有告訴你有多少組數(shù)據(jù),這個(gè)通常是最令新手疑惑的,這種情況,一般用文件結(jié)束標(biāo)志EOF判斷

            01 #include <iostream>
            02
            03 int main(void){
            04     int n;
            05     while (scanf("%d", &n) != EOF){
            06     //...
            07     }
            08     //...
            09     return 0;
            10 }

            其實(shí)這里也可以用c++的cin輸入流判斷,例如

            01 #include <iostream>
            02
            03 using namespace std;
            04
            05 int main(void){
            06     int n;
            07     while (cin>>n){
            08     //...
            09     }
            10     //...
            11     return 0;
            12 }

            但是這樣不是特別好,為什么?下面會(huì)說.

            對于輸出,最好采用的接收一組數(shù)據(jù),處理一組數(shù)據(jù),把結(jié)果保存在一個(gè)緩沖數(shù)組中,待所有輸入結(jié)束后,再一起輸出,而不是待接收完所有輸入后,再處理,再輸出,這樣會(huì)消耗更多的memory,而且會(huì)更慢.

            2.關(guān)于效率

            第一,上面的所有例子,均采用的c標(biāo)準(zhǔn)I/O,為什么不用c++的cin,cout呢?是有原因的,經(jīng)實(shí)踐,在大規(guī)模輸入輸出下,cin,cout效率遠(yuǎn)遠(yuǎn)低于scanf()和printf(),原因據(jù)我估計(jì)應(yīng)該是以為scanf(),printf()是匯編寫的(這點(diǎn)可以從這兩個(gè)函數(shù)均可以接受任意多組parameter(s)看出,c/c++函數(shù)是不具備這樣的性質(zhì)的),而cin,cout均是直接c/c++寫的流操作,本來c/c++就比匯編慢,還引入流,所以自然比scanf(),printf()慢了.因此,在輸入輸出數(shù)據(jù)量很小的情況下,出于方便的原因,可以采用cin,cout,而在輸入輸出數(shù)據(jù)量比較大的情況下用scanf(),printf()比較保險(xiǎn),避免超時(shí).

            第二.ACM中,除了c/c++,一般還支持java等語言,但是由于java是解釋執(zhí)行的,效率十分低下,為此,一般的JudgeOnline都把java的time limit設(shè)置為題目給定值(也就是c/c++的time limit)的三倍,而且給每一組輸入再額外提供150ms.即使是這樣,java遇上復(fù)雜或者高精度計(jì)算的題目,還是很容易超時(shí),因?yàn)樾视袝r(shí)候還遠(yuǎn)遠(yuǎn)未到c/c++的1/3.因此,一般來說,除了個(gè)別java極其有利的情況(例如字符串處理),不建議使用java.

            3.關(guān)于所得結(jié)果的解釋

            下面是一般JudgeOnline系統(tǒng)所有可能產(chǎn)生的結(jié)果,如果對返回的結(jié)果不明,看看解釋吧

            Waiting: Your program is being judged or waiting to be judged.

            Accepted (AC): Congratulations! Your program has produced the correct output!

            Presentation Error (PE): Your program's output format is not exactly the same as required by the problem, although the output is correct. This usually means the existence of omitted or extra blank characters (white spaces, tab characters and/or new line characters) between any two non-blank characters, and/or blank lines (a line consisting of only blank characters) between any two non-blank lines. Trailing blank characters at the end of each line and trailing blank lines at the of output are not considered format errors. Check the output for spaces, blank lines, etc. against the problem's output specification.

            Wrong Answer (WA): Your program does not produce the correct output. Special judge programs will possibly return Wrong Answer in place of Presentation Error for simplicity and robustness.

            Runtime Error (RE): Your program has failed during the execution. Possible causes include illegal file access, stack overflow, out of range in pointer reference, floating point exception, division by zero and many others. Programs that stay not responding for a long time (not consuming CPU cycles) may also be considered to have encountered runtime errors.

            Time Limit Exceed (TLE): The total time your program has run for has exceeded the limit.

            Each problem has two time limits - TOTAL TIME LIMIT and CASE TIME LIMIT. The former is the total time allowed for your program to deal with all input files. And the latter is the total time allowed for your program to deal with a single input file. Exceeding either one will lead to Time Limit Exceed. If you get Time Limit Exceed but find that your program has run for less time than is limited, your program must have exceeded that CASE TIME LIMIT.

            Problems without a special demand on the time limit for a single input file will have its case time limit is trivially set as the same as its total time limit and the phrase "Case Time Limit" will not show up under the problem title.

            Memory Limit Exceed (MLE): The maximum amount of memory that your program has used has exceeded the limit.

            Output Limit Exceed (OLE): Your program has produced too much output. Currently the limit is twice the size of the file containing the expected output. The most common cause of this result is that your programs falls into an infinite loop containing some output operations.

            Compile Error (CE): The compiler fails to compile your program. Warning messages are not considered errors. Click on the judge's reply to see the warning and error messages produced by the compiler.

            No such problem: Either you have submitted with a non-existent problem id or the problem is currently unavailable (probably reserved for upcoming contests).

            System Error: The judge cannot run your program. One example is that your program requires much more memory than hardware limitation.

            Validate Error: The special judge program fails in checking your output, which means it may contain some bugs. If you get this result, please contact the administrator. (Of course, this also means your output is probably wrong).

            posted on 2009-11-11 00:43 iZ 閱讀(1838) 評論(11)  編輯 收藏 引用

            評論

            # re: [轉(zhuǎn)載]ACM技巧——for amateur only 2009-11-11 03:17 OwnWaterloo
            "經(jīng)實(shí)踐,在大規(guī)模輸入輸出下,cin,cout效率遠(yuǎn)遠(yuǎn)低于scanf()和printf()"
            遠(yuǎn)遠(yuǎn)低于? 太夸張了……
            野蠻人拿到打火機(jī)可能也會(huì)抱怨"還不如我的木頭"。

            看看這個(gè):
            http://acm.pku.edu.cn/JudgeOnline/problemstatus?problem_id=2602

            第1個(gè)uther的,就是用C++ iostream做的。

              回復(fù)  更多評論
              

            # re: [轉(zhuǎn)載]ACM技巧——for amateur only 2009-11-11 19:16 iSsay
            @OwnWaterloo
            uther只是預(yù)處理包含了流處理的定義,但是他有沒有調(diào)用cin/cout那我就不知道了。  回復(fù)  更多評論
              

            # re: [轉(zhuǎn)載]ACM技巧——for amateur only 2009-11-11 19:19 iSsay
            @OwnWaterloo
            換句話說,說不定他預(yù)先包含的是iostream,里面用的都是匯編代碼呢
            :-)  回復(fù)  更多評論
              

            # re: [轉(zhuǎn)載]ACM技巧——for amateur only 2009-11-11 20:30 OwnWaterloo
            @iSsay
            少扯了,uther是我臨時(shí)注冊的馬甲。

              回復(fù)  更多評論
              

            # re: [轉(zhuǎn)載]ACM技巧——for amateur only 2009-11-11 21:12 iSsay
            @OwnWaterloo
            我有眼不識泰山,大牛啊,能看看你的代碼嗎?  回復(fù)  更多評論
              

            # re: [轉(zhuǎn)載]ACM技巧——for amateur only 2009-11-11 21:26 OwnWaterloo
            @iSsay
            就事論事而已,我不是大牛,pku上就沒過幾道題。
            代碼里面有很多速度測試的代碼,所以很長。

            其實(shí)是用istream::read 一次讀完所有輸入到buf。
            將buf[0],buf[2],buf[4], ... 看作a
            將buf[1],buf[3],buf[5], ... 看作b
            然后高精度加高精度。
            加法時(shí)沒有沒有轉(zhuǎn)換到0-9 直接用'0'-'9'計(jì)算,輸出時(shí)也省去了另一次轉(zhuǎn)換,直接輸出一個(gè)字符串。

              回復(fù)  更多評論
              

            # re: [轉(zhuǎn)載]ACM技巧——for amateur only 2009-11-11 23:02 iSsay
            你有沒有試過,用測速代碼測試iostream,和標(biāo)準(zhǔn)IO的效率?  回復(fù)  更多評論
              

            # re: [轉(zhuǎn)載]ACM技巧——for amateur only 2009-11-11 23:05 OwnWaterloo
            @iSsay
            標(biāo)準(zhǔn)IO?cin,cout,cerr,clog不就是標(biāo)準(zhǔn)IO么?

            你指的是formatted io?

              回復(fù)  更多評論
              

            # re: [轉(zhuǎn)載]ACM技巧——for amateur only 2009-11-12 00:08 OwnWaterloo
            @iSsay
            這個(gè)嘛,你去測吧,嘿嘿。


            做2602的背景是這樣的:chinaunix上有人說poj上有題目建議使用scanf/printf,否則做不出來。
            然后我就去試了試。 先隨便在網(wǎng)上扒了一份代碼,TLE……
            干脆自己寫,用g++提交,結(jié)果就過了,換c++提交,第2次就跳到no1去了。
            不過oj上的時(shí)間測不準(zhǔn),精度太低。其他人多提交幾次可能也會(huì)沖到no1去。


            iostream的格式化是靜態(tài)分派的,printf/scanf是動(dòng)態(tài)分派。
            在格式化上,iostream的機(jī)制理論上的效率是會(huì)高而不是低。

            iostream輸在格式化后的其他事情上去了。iostream下還有一層client可知的streambuf層次。

            iostream多這一個(gè)層次,就將"格式化"與"緩沖"工作分開了。
            你可以復(fù)用iostream的格式化功能,但給它一個(gè)不同于file的目的地,比如socket、memory、null —— 只要傳遞給它相應(yīng)的streambuf就行。

            對于memory作為目的地,stl提供了stringbuf。并有相應(yīng)的stringstream在iostream上增加一些接口,使得client不用直接操縱stringbuf。
            C標(biāo)準(zhǔn)庫相應(yīng)有sprintf,sscanf。但要這么看,sprintf不能擴(kuò)容。
            類似的還有在我最開始接觸vector的時(shí)候,也覺得它慢。因?yàn)槲夷胿ector和固定大小數(shù)組比較。但當(dāng)我不做oj,數(shù)組大小不方便提前計(jì)算出時(shí),怎么辦?
            而且,stl其實(shí)還有strstream……

            以socket作目的地? printf/scanf怎么搞?
            自己實(shí)現(xiàn)printf/scanf嗎? 你覺得這容易嗎?
            如果不自己實(shí)現(xiàn)printf/scanf,那就只能利用緩存。
            拿這種情況和iostream + socketbuf比較,那才公平。

            iostream還有很多亂七八糟的功能,locale,expcetion,callback,fillchar……

            總之,在一個(gè)只處理build-in類型,數(shù)組/緩沖大小可以提前計(jì)算并按最大值提供,不需要按需提供/擴(kuò)展,不處理多語言的情況下 —— OJ的情況下 ——確實(shí)利用不了iostream,vector等提供的功能。
            但OJ做多了,就反過來說它們的不是,就很扯蛋了。
            說實(shí)話,OJ的代碼普遍是上不得臺(tái)面的,大家自己心里清楚。
            根本就沒有一點(diǎn)點(diǎn)軟件工程的美感在里面??蓮?fù)用嗎?不能,都是一次性筷子,完全是為了AC而已。

            在實(shí)際開發(fā)中,沒有這么多美好的前提條件。

            即使iostream功能比printf/scanf多得多,如果iostream的格式化比printf/scanf有數(shù)量級的差異,沒得說,那肯定是iostream實(shí)現(xiàn)得太爛……
            同樣的是格式化和讀寫文件操作,多一個(gè)間接層次就導(dǎo)致效率數(shù)量級的下降?那不是寫得爛能是什么呢?找個(gè)好點(diǎn)的吧。
            還有用VC6的OJ(非POJ),你能拿它怎么辦呢?

              回復(fù)  更多評論
              

            # re: [轉(zhuǎn)載]ACM技巧——for amateur only 2009-11-12 14:38 OwnWaterloo
            好像說偏題了……

            chinaunix上討論時(shí),他并沒有說是哪一題,只說有題目提示說要用scanf/printf。他自己也記不清楚是哪一題了。
            2602是我自己找出來的,覺得這題比較變態(tài)。

            如果樓主在做其他題目時(shí),發(fā)現(xiàn)題目下面有提示說使用scanf/printf的話,還請通知我一下,謝謝~_~
              回復(fù)  更多評論
              

            # re: [轉(zhuǎn)載]ACM技巧——for amateur only 2009-11-15 16:25 iSsay
            @OwnWaterloo
            POJ2602上面那道題,可能沒有體現(xiàn)出printf的優(yōu)點(diǎn)吧。如果加上格式控制就不一樣了。
            那個(gè)hint估計(jì)也就是這個(gè)意思,就有點(diǎn)像入門題,先給你一個(gè)提示,讓你以后做題的時(shí)候考慮到printf。。
              回復(fù)  更多評論
              

            国产精品久久久久一区二区三区| 久久人人爽人人爽人人AV东京热| 久久精品国产亚洲麻豆| 91亚洲国产成人久久精品网址| 成人精品一区二区久久| 久久国产精品免费一区二区三区| 久久亚洲AV永久无码精品| 亚洲精品国产综合久久一线| 色欲久久久天天天综合网| 国产欧美久久一区二区| 欧美一级久久久久久久大片 | 九九久久自然熟的香蕉图片| 久久香蕉国产线看观看乱码| 伊人久久大香线蕉综合网站| 久久精品国产第一区二区三区| 国内精品久久久久影院网站| 久久人人爽人人爽人人片AV高清| 久久久一本精品99久久精品88| 66精品综合久久久久久久| 亚洲色婷婷综合久久| 欧美久久久久久精选9999| 狠狠色丁香久久综合婷婷| 欧美精品乱码99久久蜜桃| 国内精品久久久久国产盗摄| 久久综合给合久久狠狠狠97色| 色综合久久88色综合天天 | 久久91精品国产91久久小草| 亚洲午夜久久久久久久久久| 久久福利片| 久久精品国产亚洲7777| 久久午夜电影网| 女人香蕉久久**毛片精品| 久久婷婷五月综合色高清| 精品久久久无码21p发布| 国产精品乱码久久久久久软件| 91久久香蕉国产熟女线看| 久久精品国产第一区二区三区| 蜜臀av性久久久久蜜臀aⅴ麻豆| 久久天天躁夜夜躁狠狠躁2022| 伊人久久大香线蕉成人| 久久久久波多野结衣高潮|