OIers的那些痛苦

这一篇文章为将要开考的朋友们列举并尽量帮助大家规避一些易错点。

一、long long与高精度

OI界有句古话：“十年OI一场空，不开long long见祖宗。”由此可见long long这个易错点。

我们知道，普通int类型的存储极限是2147483647。当某个数字超过了这一范围后，我们就需要使用long long int来定义存储数字的变量(注意：不要使用long int，它等于int，没有意义)。

但我们知道，long long int也是有极限的。它的极限为9223372036854775807。当数字超过这个极限，我们就必须使用字符串或数组存储。

总的来说，long long是一个微小但致命的点。如果你忽视了它，你就得做好一半的测试点爆RE的准备。

二、交换后置问题

这个标题是我自己杜撰的一个词。但，它却能生动地展现这种问题的本质——无视代码中的修改，按原样去写接下来的代码。

打个比方，三角交换法。代码如下：

int a,b,c;
cin>>a>>b>>c;
c=a; a=b; b=c;

在这个代码中，c的存在就是用于避免这种问题——如果直接a=b，b=a，那会引起我们不想要的奇怪结果：因为在b=a执行时，a已经是b了，所以结果将是两个b。这种问题的存在，就是忽视了a=b而直接去写b=a的后果。

再打个比方，来看看以下代码：

//这段代码是要求出长度为n的a数组中第一个3的倍数与数组中3的倍数的数量的积与1~数组中3的倍数的数量的和的和
int sum=0,ans=0;
bool b=false;
for(int i=0;i<n;i++){
    if(i%3==0){
        if(!b) b=true;
        sum++;
    }
    ans+=i+sum;
}
cout<<ans;

我们发现，i本身在变化，但这里错误地把ans赋值语句中的i认为一直是第一个3的倍数。这也是无视了i++导致的。

看了这两个例子，我们发现这个问题会渗透在各种各样的代码里，且很多时候难以检查，其对最终答案的影响更是极度致命，搞不好就全部WA掉。我们一定要小心它。

三、总结

因为每个人的码风和使用的算法不同，问题也是多种多样的。只有在检查代码时格外注意这些微小的刺客，才能保证我们的AC。

祝各位信息与未来、CSPJ、CSPS、NOIP，乃至IOI都能拿下一个奖项！