• <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++博客 :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理 ::
              13 隨筆 :: 0 文章 :: 25 評論 :: 0 Trackbacks

            1.輸入輸出

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

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

            (2).固定組數的輸入,可以利用一個計數器和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).測試數據結尾有標志字符(例如最后一組輸入后給一個0),這個只用加一個if語句判斷讀入的數據是什么,是結束標志跳出就ok了.也不多說了

            (4).題目沒有告訴你有多少組數據,這個通常是最令新手疑惑的,這種情況,一般用文件結束標志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 }

            其實這里也可以用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 }

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

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

            2.關于效率

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

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

            3.關于所得結果的解釋

            下面是一般JudgeOnline系統所有可能產生的結果,如果對返回的結果不明,看看解釋吧

            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: [轉載]ACM技巧——for amateur only 2009-11-11 03:17 OwnWaterloo
            "經實踐,在大規模輸入輸出下,cin,cout效率遠遠低于scanf()和printf()"
            遠遠低于? 太夸張了……
            野蠻人拿到打火機可能也會抱怨"還不如我的木頭"。

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

            第1個uther的,就是用C++ iostream做的。

              回復  更多評論
              

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

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

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

              回復  更多評論
              

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

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

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

              回復  更多評論
              

            # re: [轉載]ACM技巧——for amateur only 2009-11-11 23:02 iSsay
            你有沒有試過,用測速代碼測試iostream,和標準IO的效率?  回復  更多評論
              

            # re: [轉載]ACM技巧——for amateur only 2009-11-11 23:05 OwnWaterloo
            @iSsay
            標準IO?cin,cout,cerr,clog不就是標準IO么?

            你指的是formatted io?

              回復  更多評論
              

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


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


            iostream的格式化是靜態分派的,printf/scanf是動態分派。
            在格式化上,iostream的機制理論上的效率是會高而不是低。

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

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

            對于memory作為目的地,stl提供了stringbuf。并有相應的stringstream在iostream上增加一些接口,使得client不用直接操縱stringbuf。
            C標準庫相應有sprintf,sscanf。但要這么看,sprintf不能擴容。
            類似的還有在我最開始接觸vector的時候,也覺得它慢。因為我拿vector和固定大小數組比較。但當我不做oj,數組大小不方便提前計算出時,怎么辦?
            而且,stl其實還有strstream……

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

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

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

            在實際開發中,沒有這么多美好的前提條件。

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

              回復  更多評論
              

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

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

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

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

            亚洲国产成人久久综合区| 久久亚洲AV成人无码| 国产成人精品综合久久久| 久久天天躁狠狠躁夜夜2020老熟妇| 久久国产精品免费一区二区三区 | 亚洲色欲久久久久综合网| 久久亚洲国产成人影院网站| 日本WV一本一道久久香蕉| 国产欧美一区二区久久| 久久综合伊人77777| 久久精品国产99久久无毒不卡| 国产高潮久久免费观看| 国产69精品久久久久久人妻精品 | 无码任你躁久久久久久久| 无码AV波多野结衣久久| 激情五月综合综合久久69| 蜜臀久久99精品久久久久久小说 | 色欲av伊人久久大香线蕉影院| 久久福利青草精品资源站| 99久久99久久精品国产片果冻| a级毛片无码兔费真人久久| 久久精品a亚洲国产v高清不卡| 久久亚洲中文字幕精品一区四| 久久ZYZ资源站无码中文动漫| 一本一本久久a久久精品综合麻豆| 国产亚洲美女精品久久久久狼| 久久青青草视频| 日本亚洲色大成网站WWW久久| 亚洲乱亚洲乱淫久久| 久久精品aⅴ无码中文字字幕重口| 久久笫一福利免费导航 | 人人狠狠综合88综合久久| 精品免费久久久久国产一区| 日本道色综合久久影院| 久久精品9988| 精品多毛少妇人妻AV免费久久| 国内精品久久国产大陆| 99久久成人国产精品免费| 久久精品亚洲精品国产色婷| 77777亚洲午夜久久多喷| 人妻无码久久一区二区三区免费|