试验进行一亿次转换的时间,结果相同,说明这两个在将字符串转换为整数时基本没区别.(40多秒差0.x秒,应该算是没差别吧)
一直在头脑里想是不是int.Parse效率是不是高些......
呵呵,这下可以放心的使用Convert.ToInt32()了.同时试验了一下加不加try{}catch{}的情况,结果说明:在不出现异常的时候,加与不加try{}catch{}块程序的运行效率一样.呵呵,原来不知听哪个说加了会影响效率,害我一直在心里想这里要不要加上......如果还有哪位在疑惑的话......听我的话:大胆的try吧!
一直在头脑里想是不是int.Parse效率是不是高些......
呵呵,这下可以放心的使用Convert.ToInt32()了.同时试验了一下加不加try{}catch{}的情况,结果说明:在不出现异常的时候,加与不加try{}catch{}块程序的运行效率一样.呵呵,原来不知听哪个说加了会影响效率,害我一直在心里想这里要不要加上......如果还有哪位在疑惑的话......听我的话:大胆的try吧!
-----------------------------------------------------------------------------------
这个还是不要乱用的好，的确是影响效率的
所以需要加的地方还是一定要加的，不过，好用也不能乱用
try{id=Convert.ToInt32(Request["id"]);}
catch{id=0;}这句有没有更好的办法?
我发现我的程序里绝大部分文件都用到了这几句话
================>
这两个方法的最大不同是它们对null值的处理方法：Convert.ToInt32(null)会返回0而不会产生任何异常，但int.Parse(null)则会产生异常。没搞清楚Convert.ToInt32和int.Parse()的细细微区别时千万别乱用，否则可能会产生无法预料的结果，举例来说：假如从url中取一个参数page的值，我们知道这个值是一个int，所以即可以用Convert.ToInt32(Request.QueryString["page"])，也可以用,int.Parse(Request.QueryString["page"])，但是如果page这个参数在url中不存在，那么前者将返回0，0可能是一个有效的值，所以你不知道url中原来根本就没有这个参数而继续进行下一下的处理，这就可能产生意想不到的效果，而用后一种办法的话没有page这个参数会抛出异常，我们可以捕获异常然后再做相应的处理，比如提示用户缺少参数，而不是把参数值当做0来处理。
路过....................
学习试验进行一亿次转换的时间的测试方法.....
不管你说的对不对
让我受教育了
和int.Parse()其实是同一个方法.在.net framework中,Convert.ToInt32(string)原型是这样子public static int ToInt32(string value)
{
if (value == null)
{
return 0;
}
return int.Parse(value, CultureInfo.CurrentCulture);
}所以...其实两个是一样的.最后真正调用执行转换的方法是private static unsafe bool ParseNumber
但实际上,正如你试验的,这个判断几乎不需要时间
我觉得反正id肯定是整型,且大于0的,直接转为整型可以省却不少麻烦. 有效性验证等都要方便.