| № | Пользователь | Рейтинг |
|---|---|---|
| 1 | ecnerwala | 3649 |
| 2 | Benq | 3581 |
| 3 | jiangly | 3578 |
| 4 | orzdevinwang | 3570 |
| 5 | Geothermal | 3569 |
| 5 | cnnfls_csy | 3569 |
| 7 | tourist | 3565 |
| 8 | maroonrk | 3531 |
| 9 | Radewoosh | 3521 |
| 10 | Um_nik | 3482 |
| Страны | Города | Организации | Всё → |
| № | Пользователь | Вклад |
|---|---|---|
| 1 | maomao90 | 174 |
| 2 | awoo | 164 |
| 3 | adamant | 161 |
| 4 | TheScrasse | 159 |
| 5 | nor | 158 |
| 6 | maroonrk | 156 |
| 7 | -is-this-fft- | 152 |
| 8 | SecondThread | 147 |
| 9 | orz | 146 |
| 10 | pajenegod | 145 |
As you might know, stderr doesn't affect a judgement. Therefore, if you use stderr instead of stdout for debugging, you won't get WA even if you forget to delete (or comment out) the lines for debugging.
Of course, you can never get AC if your solution is wrong in the first place :)
the runtime of the above code would surely decrease if the
cerrstatements were removed.and if the recursion runs for nearly 106 nodes, it could easily result in the solution getting TLE instead of AC.
We are facing a trade-off between coding time and running time.
When our solution seems good, we should remove some debugging statements which consump much time. I think it is good idea.
Oh, sorry. I completely forgot an effect on running time. Certainly, the effect of debugging statements in such a case cannot be ignored. Therefore, please think using stderr instead of stdout is only an insurance against WA.
Codeforces defines an
ONLINE_JUDGEmacro for C/C++ programs. Therefore it is possible to write a template where the debugging output works on a local machine, and turns into nothing on Codeforces. A very simple implementation:Then just write
LOG(i);in the program.Thanks for a wonderful macro!
Deleting cerr's when submitting can be done in a following way: 1. Replace (Ctrl+R in Kate)
:P
Defining own macros is a good idea, but sometimes we want something mote than just printing the value of a variable (for example additional comments written by us to make them readable). By the way if we have macro in our code like that LOG(x) and use it in a code, we should take care of line with that define in a replace method I explained earlier :P.
Well, we may define so that it's as easy to write comments to it as to cerr (Well not very easy:) )
But you should be careful with values like LOG(1<<2)
In my actual implementation of
LOG()(which uses C++11 variadic templates) this works: the codeint a = 42; vector<int> b = { 1, 2, 3 }; LOG(a, b, "comment");will print
It's not much, but I'll try to polish the code and put it on Github so that other people can see it sometime later.
Can you share your source?, the macro LOG(...) is great.
http://ideone.com/y39aaF
It doesn't give WA but actually it does give TLE check out 76023053 gives TLE and the other 76022926 is Accepted.
So it's always better to comment out or delete stderr statements before submitting
Yes.
That was the idea behind the very first comment written under this post.
Six years ago.
I'm getting WA while using stderr. wrong solution using cerr (debug(u)) 178151957. Correct solution by commenting that line 178151812. Am I missing something?
It has nothing to do with cerr rather your for-loop and
#define debug(x).When you uncomment
// for(auto u: temp) debug(u)m[h]++;m[h] get incremented because for-loop never finds a
;neither after youdebug(u)nor in your#define debug(u)Either put a
;in#define debug(u) ;or afterdebug(x)in for loop or wrap it in{}.Flower08 thanks for helping I was missing such a silly thing. Btw I saw your profile, it seems like your cf journey is quite similar to mine.