这个跟符号应该没关系，signed的加减乘除也有一样的惊喜

如果要求高的话，应该对加减乘除操作设计专门的操作函数，里面在计算之前先比较是否会溢出、除零等，就像Rust干的那样

【 在 iwantfly 的大作中提到: 】
: 无符号数加减乘除，太多惊喜
:
--
修改:z16166 FROM 125.33.229.*
FROM 125.33.229.*

std::vector sss = .....
for(int i=0; i<ss.size()-1; ++i)

ss是空的时候就很二逼了...

返回size_t绝对是异端,标准库就是各种让你不舒服

除了嵌入式和二进制处理等少量领域,计数和计算方面都不应该出现无符号


【 在 GoGoRoger (GoGoRoger) 的大作中提到: 】
: 标  题: Re:size_t和int比较时哪种写法效率更高？
: 发信站: 水木社区 (Wed Aug 12 17:57:13 2020), 站内
:
: 以前居然没细想过，不过这种情况应该不多。
: 【 在 iwantfly 的大作中提到: 】
: :  
: : 无符号数加减乘除，太多惊喜  
: :  
: : --
:
: 发自「今日水木 on Mi Note 3」
: --
: 生活好无趣，到水木吵架去。
:
: ※ 来源:·水木社区 http://www.newsmth.net·[FROM: 101.199.100.*]
--
FROM 171.83.95.*

这锅为啥要让size_t来背

特殊情况、边界情况，本身就需要码农自己注意

【 在 libgcc 的大作中提到: 】
: std::vector sss = .....
: for(int i=0; i<ss.size()-1; ++i)
: ss是空的时候就很二逼了...
: ...................
--
FROM 125.33.229.*

不用 Rust 那么时髦，四十年前的 BASIC 就能在计算溢出时报错了。

【在z16166的大作中提到:】:
这个跟符号应该没关系，signed的加减乘除也有一样的惊喜
如果要求高的话，应该对加减乘除操作设计专门的操作函数，里面在计算之前先比较是否会溢出、除零等，就像Rust干的那样
--
FROM 138.19.103.*

接口中不要用size_t，其他的还好。

不过能用int就用int，size_t长度变化有时候（大多数时候）非常不好。

【 在 jsznzsj 的大作中提到: 】
:
: int n;
: vector vec;
:
: 是 (size_t)n < vec.size() 还是 n < (int)vec.size() 效率高？假设64位程序。
--
FROM 117.10.203.*