size_t 是无符号的整型,int 是 有符号的整型。
1.关于size_t的定义size_t是一种数据相关的无符号类型,它被设计得足够大以便能够内存中任意对象的大小。 在cstddef头文件中定义了size_t类型,这个文件是C标准库stddef.h头文件的C++版本。 关于百度百科: size_t概述: size_t 类型定义在cstddef头文件中,该文件是C标准库的头文件stddef.h的C++版。它是一个与机器相关的unsigned整型类型,其大小足以保证存储内存中对象的大小。 size_t由来: 在C++中,设计 size_t 就是为了适应多个平台的 。size_t的引入增强了程序在不同平台上的可移植性。 在需要通过数组下标来访问数组时,通常建议将下标定义size_t类型,因为一般来说在进行下标访问时,下标都是正的。当然,也不是所有的下标访问操作下标都是正的,比如以下代码: int a[10]={1,2,3,4,5,6,7,8,9,10}; int * ptr =&(a[4]); cout<<ptr[-2]<<endl; 这段代码中对ptr进行了下标访问,并且下标是负的,但是这个访问并不是错误的,执行的结果是输出3。
2.size_t占用的真实空间size_t大小: 关于size_t占用的空间百度百科的描述是:经测试发现,在32位系统中size_t是4字节的,而在64位系统中,size_t是8字节的,这样利用该类型可以增强程序的可移植性。 疑问百度百科和网上猿友的描述看似很有道理,但是很多人在测试的时候发现,为什么测试环境明明是64位的系统,sizeof(size_t)的值却等于4呢?而不是原本预期的8。 本机环境是Win7 64bits,使用VS2012来验证。 本机系统类型: 测试代码:
输出结果: 疑问解答: 为什么会这样,我之前一直也弄不明白。原来网上说的size_t的大小由系统的位数决定是不准确的。那size_t的大小究竟是由什么决定的呢? 先看一下我刚刚测试代码的VS2012的编译配置。配置如下:
VC++中关于size_t类型的定义如下:
其大概的意思就是size_t要么是unsigned int,要么是unsigned long int,那么按照上面的推理,修改编译选项为x64,生成64bits的程序,size_t的类型是不是就变成了unsigned long int了呢?验证如下: VS2012的编译配置更改如下: 同样的测试代码:
输出结果为: 总结:size_t的大小并非像很多网上描述的那样,其大小是由系统的位数决定的。size_t的大小是由你生成的程序类型决定的,只是生成的程序类型与系统的类型有一定关系。32bits的程序既可以在64bits的系统上运行,也可以在32bits的系统上运行。但是64bits的程序只能在64bits的系统上运行。然而我们编译的程序一般是32bits的,因此size_t的大小也就变成了4个字节。 由此引发指针的大小的问题? 关于指针的大小,网上描述基本上是千篇一律,认为指针是存放地址的,如果是32位机器就是4字节的,如果是64位机器就是8字节的,根据机器字而决定的。 这里的32位机器和64位机器指的是什么呢?我觉的CPU的架构决定了机器的类型,如果CPU是x86架构,那么就是32位的CPU,当然并非所有的x86架构的CPU都是32位的,比如intel的8086和8088就是16位的CPU。 如果CPU是x86-64的架构,那么就是64位的CPU。CPU的位数是由其字长决定,字长表示CPU在同一时间中能够处理二进制数的位数叫字长。字长是由CPU中寄存器的位数决定的,并非由数据总线的宽度决定的,只是数据总线的宽度一般与CPU的位数相一致。 系统的位数是依赖于CPU的位数,即32位的CPU不能装64位的系统,但是现在(2015年)的CPU基本上都是x86-64的CPU,都支持64位的系统。但是正如上面的讨论,如果编译生成的程序不是64位的,那么指针的大小依然是4个字节。 验证如下: VS2012的编译配置如下:
输出结果: 更改编译配置,生成64位的程序,我们将得到预想的结果: 3.size_t的作用某些情况下正确的使用size_t可以提高程序的可移植性和有效性。 4.为什么size_t重要?为什么size_t重要?(Why size_t matters)10 September 2014
之前在《内存拷贝的注意事项》一文中提到过size_t,可能许多人对这个类型不太熟悉没有用过或者根本不敢去用,最近看到一篇文章对这个类型讲的比较详细,便翻译过来让不熟悉的同学可以知道它产生的原因以及如何使用。 前言:使用size_t可能会提高代码的可移植性、有效性或者可读性,或许同时提高这三者。 在标准C库中的许多函数使用的参数或者返回值都是表示的用字节表示的对象大小,比如说malloc(n) 函数的参数n指明了需要申请的空间大小,还有memcpy(s1, s2, n)的最后一个参数,表明需要复制的内存大小,strlen(s)函数的返回值表明了以'\0'结尾的字符串的长度(不包括'\0'),其返回值并不是该字符串的实际长度,因为要去掉'\0'。 memcpy和strlen的申明应该出现在中: size_t还经常出现在C++标准库中,此外,C++库中经常会使用一个相似的类型size_type,用的可能比size_t还要多。 可移植性问题 早期的C语言(由Brian Kernighan 和 Dennis Ritchie 在The C Programming Language书中所写,Prentice-Hall, 1978)并没有提供size_t类型,C标准委员会为了解决移植性问题将size_t引入,举例如下: 使用int类型在大部分情况下都是可以的,但是并不是所有情况下都可以。int是有符号的,它可以表示负数,但是,大小不可能是复数。所以我们可以使用unsigned int代替它让第三个参数表示的范围更大。 这样似乎没有问题了,unsigned int可以表示最大类型的对象大小了,这种情况只有在整形和指针类型具有相同大小的情况下,比如说在IP16中,整形和指针都占2个字节(16位),而在IP32上面,整形和指针都占4个字节(32位)。(参见下面C数据模型表示法) 不幸的是,这种memcpy的申明在I16LP32架构上(整形是16-bit 长整形和指针类型时32-bits)显得不够用了,比如说摩托罗拉第一代处理器68000,在这种情况下,处理器可能拷贝的数据大于65535个字节,但是这个函数第三个参数n不能处理这么大的数据。 你可以在I16LP32目标架构上使用这个函数了,它可以处理更大的数据。而且在IP16和IP32平台上效果也还行,说明它确实给出了memcpy的一种移植性较好的申明。但是,在IP16平台上相比于使用 使用size_t 转自http://jeremybai.github.io/blog/2014/09/10/size-t/ size_t的定义在 考虑到可移植性和程序效率,n应该被申明为size_t类型。类似的,下面的foo函数的参数也应当被申明为sizeof: 参数中带有size_t的函数通常会含有局部变量用来对数组的大小或者索引进行计算,在这种情况下,size_t是个不错的选择。 | ||
使用 size_t 可以增加代码的可移植性。