hust 1606 cout&&printf（有毒）

G - GTime Limit:3000MS     Memory Limit:131072KB     64bit IO Format:%lld& %lluSubmit Status Practice HUST1606DescriptionGive you a positive integer x, determine whether it is the sum of three positive cubic numbers.InputThere’re several test cases. For each case: Only one line containing an integer x ( 1≤x≤10^6)OutputFor each test case, print “Yes” if it is or “No” if it isn’t. (See sample for more details)Sample Input

1
3
10

Sample Output

No
Yes
Yes

#include <iostream>
#include<cstdio>
#include<cstring>
using namespace std;
int i,j,x,flag,k;
int a[105],f[2000002];
int main()
{
memset(f,0,sizeof(f));
for(i=1;i<=100;i++)
a[i]=i*i*i;

for(i=1;i<=100;i++)
for(j=1;j<=100;j++)
f[a[i]+a[j]]=1;

while(~scanf("%d",&x))
{
flag=0;
for(i=1;i<=100;i++)
if (x>a[i])
if (f[x-a[i]]) {flag=1; break;}
if(flag) printf("Yes\n"); else printf("No\n");
}

return 0;
}

烦死啦。。。。。。。。。。。。。。。。。。

#include <iostream>
#include<cstdio>
#include<cstring>
using namespace std;
int f[2000002];
int main()
{
int i,j,k,a[105];
memset(f,0,sizeof(f));
for(i=1;i<=100;i++){
a[i]=i*i*i;
}
for(i=1;i<=100;i++){
for(j=1;j<=100;j++){
f[a[i]+a[j]]=1;
}
}
int x,g;
while(~scanf("%d",&x)){
g=0;
for(i=1;i<=100;i++)
if(x>a[i])//<一定要判断>
if(f[x-a[i]]){g=1;break;}
if(g==0)cout<<"No"<<endl;
else cout<<"Yes"<<endl;
}
return 0;
}

终于好啦。。。。竟然把cout改成printf就对了。。。。。。。。。。。。有毒啊。。。。。。。。。。。。。。。。。。。。。。。。

loading。。。。。。。。。。。

剧毒啊。。。。。。。。。。。。。第一次出错是开数组开的大忘了放在外面。。。。。。。。。。第二次就是cout。。。。。。。。。。

输入输出超过1W不要用cin  cout。。。。。。。

以下是复制的别人的文字

昨天在OJ上看到一个很水的题，题意就是两个递增序列，输出合并后新序列的中值(详细描述可参见我的另一篇文章http://hi.baidu.com/i5love1you9/blog/item/250f57d671b6f41aa08bb721.html)。当时也闲来无事，于是决定动手写写。刚开始也没怎么在意，认为该题随便都能AC。可提交的结果却TLE了，当时就郁闷了，这算法不可能会有问题啊，不就是一个简单的归并而已，我写的再搓也不可能会TLE啊（小小地自恋一下，哈哈）。我坚信算法肯定是没问题的，那问题究竟出在哪儿了呢？很快便锁定问题的症结在于输入输出，其实刚开始并不确定，虽然很早以前就知道cin，cout比scanf，printf要慢，可一直没在意，认为即使有差别也不会太大吧，但这次“血淋淋”的事实就是cin，cout就TLC，scanf，printf就AC了。于是，一个问题“cin,cout与scanf，printf速度上的差别到底有多大”便出现在脑海中。晚上跑步的时候，将该问题告诉了霏哥，霏哥测试了cin与scanf，但结果却大大出乎了我们的预料，cin竟然比scanf快！怎么回事？这不可能啊，难道霏哥的方法不对，这也不大可能啊(我可是绝对相信霏哥的哦，哈哈)。

在VS1010上测试的结果是：cin 0.234s,scanf 0.421s。怎么回事？真的如霏哥所测的，cin竟然比scanf快。这下我彻底懵了，这到底是怎么回事？ 于是上网百度，找了好久才看到相关一篇文章，作者分别测试了linux和windows平台上常用的几款编译器下scanf和cin的速度，结果显示scanf至少要比cin快一倍左右。文中还指出cin慢的原因是，默认情况，cin与stdin总是保持同步的，也就是说这两种方法可以混用，而不必担心文件指针混乱，同时cout和stdout也一样，两者混用不会输出顺序错乱。正因为这个兼容性的特性，导致cin有许多额外的开销，如何禁用这个特性呢？只需一个语句std::ios::sync_with_stdio(false);，这样就可以取消cin于stdin的同步了，此时的cin就与scanf差不多了。     但是为什么我在VS2010上测试的结果却大相径庭呢？莫非是测试方法不对？这不可能啊，我个人这点自信还是有的。那这到底是什么原因呢？带着满脑子的疑问和不解，我继续看着那篇文章，终于在评论部分，有位网友提到，cin、cout是在编译期间就决定了读入变量的类型。而scanf()是在运行期决定的，编译器无法优化，而且还要识别字符串。理论上scanf比cin要慢很多，实际上快的原因是很多编译器对cin、cout的处理过于保守。按着这位网友的说法，理论上cin，cout比scanf，printf要快，实际中是由于编译器的处理方式导致了scanf，printf比cin，cout快了。      带着疑问，我又用g++测试了一下，当然没有带任何优化选项，g++版本为4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)。结果果然是我预期的：cin 1.1s ，scanf 0.41s。      这似乎证实了理论上cin，cout比scanf，printf要快，实际中是由于编译器的处理方式导致了scanf，printf比cin，cout快了，至少我的实验结果是和这个说法稳合的。也许还有其他的原因，恳请各位牛人网友热心赐教，鄙人将感激不尽。      最后，算是一个建议吧，其实你肯定已经听别人说过很多次了，在OJ上做题尽量使用scanf和printf，尤其是有大量数据需要输入输出时，当然你也可以用取消了同步的cin。