int n;
vector<double> vec;
是 (size_t)n < vec.size() 还是 n < (int)vec.size() 效率高？假设64位程序。
jsznzsj
size_t是无符号数
除了是unsigned，size_t移植性更好，不是固定bit数目的，最大值取决于机型/编译模式。
把STL size()返回的size_t转为int什么的，不是好习惯，因为size_t在x64模式下编译可能是64-bit的。
正常应该把n定义为size_t类型，避免转换。有极端性能要求的场合另行考虑。
.......
size_t是万恶之源
取消 size_t全用int才是正统
【 在 z16166 (Netguy) 的大作中提到: 】
: 除了是unsigned，size_t移植性更好，不是固定bit数目的，最大值取决于机型/编译模式。
: 把STL size()返回的size_t转为int什么的，不是好习惯，因为size_t在x64模式下编译可能是64-bit的。
: 正常应该把n定义为size_t类型，避免转换。有极端性能要求的场合另行考虑。
: ...................
会有人往 vector/linked_list 里面写超过 2^32 数量的元素？
strlen、memcpy之类的，都是size_t
【 在 hgoldfish 的大作中提到: 】
: 会有人往 vector/linked_list 里面写超过 2^32 数量的元素？
为什么是万恶之源？
【 在 iwantfly 的大作中提到: 】
: .......
: size_t是万恶之源
: 取消 size_t全用int才是正统
道理我懂啊。我只是想问，有谁见过一次性处理 4gb 内存和 4g 元素列表的代码没？是什么场景。
: strlen、memcpy之类的，都是size_t
俺没这么用过
不过既然有这种接口，有人这么用也不奇怪吧
比如fread()一次把整个iso文件的内容全部read/map到内存中
桌面级的pc已经支持128/256G的内存，服务器的内存更大，file size也是size_t的。
: 道理我懂啊。我只是想问，有谁见过一次性处理 4gb 内存和 4g 元素列表的代码没？是什么场景。
估计是在恨unsigned吧。当时日子紧吧的时候设计的东西，很多场景下反而是坑了
: 为什么是万恶之源？
无符号数加减乘除，太多惊喜
这个跟符号应该没关系，signed的加减乘除也有一样的惊喜
如果要求高的话，应该对加减乘除操作设计专门的操作函数，里面在计算之前先比较是否会溢出、除零等，就像Rust干的那样
: 无符号数加减乘除，太多惊喜
以前居然没细想过，不过这种情况应该不多。
发自「今日水木 on Mi Note 3」
: --
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」
: 生活好无趣，到水木吵架去。
我是说犯错误机会不多，大家一般都在正数内比较
【 在 libgcc 的大作中提到: 】
: std: : vector sss = .....
: for(int i=0; i:
: ss是空的时候就很二逼了...
: 返回size_t绝对是异端,标准库就是各种让你不舒服
: 除了嵌入式和二进制处理等少量领域,计数和计算方面都不应该出现无符号
这锅为啥要让size_t来背
特殊情况、边界情况，本身就需要码农自己注意
: std::vector sss = .....
: for(int i=0; i<ss.size()-1; ++i)
挖的一手好坑
【在jsznzsj的大作中提到:】:
intn;
vector<double>vec;
是(size_t)n<vec.size()还是n<(int)vec.size()效率高？假设64位程序。
不用 Rust 那么时髦，四十年前的 BASIC 就能在计算溢出时报错了。
【在z16166的大作中提到:】:
对的
用无符号数是当年脑子被驴踢了
