优点1:可以真正地比较算法的效率,
传统的一些OJ,一道题会要求你读入数据,运行算法再输出结果,运行时间包括了“读入数据”和“输出结果”。
相信很多在OJ上刷题的筒子们多少碰到过这样的事情,(1)cin太慢了,加一句std::ios::sync_with_stdio(false); (2)scanf还是太慢了,自己写一个input函数。
LeetCode和TopCoder这样的OJ要求你写一个类的接口,在评测的时候可以有效避免计算I/O的时间。
至于为什么要写一个类包含特定接口而不是直接写一个函数,是为了避免你写的其他函数和评测系统的函数冲突。
优点2:更简单的Special Judge
如果输入的结果是整数、字符串那还好办,逐个字符比较就好了,但是是一个浮点数呢?传统的OJ一般采用Special Judge的方法,自己写一个文件读入标准Ouput的浮点数和你的结果输出的浮点数,再比较两个浮点数相差值是否在限定范围内,多解问题同理。
我们来梳理一下传统OJ的Special Judge的流程:(1)你的程序读入input.txt;(2)你的程序输出output.txt;(3)Special Judge读入output.txt;(4)Special Judge程序读入标准输出standard.txt;(5)Special Judge程序比较output.txt和standard.txt;(6)得出评测结果。
而LeetCode可以避免output.txt的I/O。
有人会说,这岂不是LeetCode每一题都要写Special Judge,差不多,但是它也可以写类似于传统OJ的逐字符比较的评测模版啊。
缺点1:在自己的电脑上运行测试样例有点麻烦。
诚然,LeetCode自己提供了运行简单样例的方法。但是,如果自己想看一下比较大的数据下自己的算法到底问题出在什么地方,显然倒腾自己的电脑更舒服。
LeetCode中,如果输入的是一组数,往往函数的参数是一个vector,自己再写一个读入转成vector难免有些难受。更甚,如果函数的参数是一个List等等,就更蛋疼了。
缺点2:提交的时候不小心就把自己的测试代码复制进去了。
自己写了个测试样例,提交的时候不小心把它包含进去了。题目里面链表已经定义了,提交的时候还有链表的定义。
这些问题挺常见的。可以通过加一个宏定义来解决,但是,不得不说,提交的时候把宏定义的注释给取消了这一步还是不可避免。相较之下,传统OJ就友善很多。