如果是用long呢？xhy 写了：在64位系统下运行32位软件 不会有任何的性能损失
大多数软件都有64bit版本 为何不用
64bit是未来的趋势
stlxv 写了：这很有可能，不过要针对多少位版本的程序来说，例如下面一段会导致内存泄露的程序：xhy 写了：另外，64位运行同样的程序，所需内存会增大。
~~~~~~~~~~~~~~~~~~~~~~~~~~~ 纯属谣言16位的话，int占用2个字节；32位的话4个字节，64位的话8个字节。代码： 全选
#include <malloc.h> int main() { malloc(sizeof(int)); return 0; }
所以，源程序同样，编译16/32/64位之后所占的内容是有区别的，而且64位会更加大。
真正跑大型应用的机器 非64位不可PhoenixJ 写了：谁用谁知道。
某些人用64位是为了炫的，而不是为了干活的——干活的机器不会非得时时刻刻想到32和64位的兼容性。累不累阿。
打碎牙齿往肚子里面吞好了，反正那样的机器仅仅是学生宿舍的机器，不是实际工作的机器。
有小白鼠在完善64位的环境，我们几年后用现成的，有何不好。
64位Unix早就很成熟了。没有这么多兼容32位的问题。xhy 写了：真正跑大型应用的机器 非64位不可PhoenixJ 写了：谁用谁知道。
某些人用64位是为了炫的，而不是为了干活的——干活的机器不会非得时时刻刻想到32和64位的兼容性。累不累阿。
打碎牙齿往肚子里面吞好了，反正那样的机器仅仅是学生宿舍的机器，不是实际工作的机器。
有小白鼠在完善64位的环境，我们几年后用现成的，有何不好。
我的结论和楼上一致。xhy 写了：你确定你试过?stlxv 写了：这很有可能，不过要针对多少位版本的程序来说，例如下面一段会导致内存泄露的程序：xhy 写了：另外，64位运行同样的程序，所需内存会增大。
~~~~~~~~~~~~~~~~~~~~~~~~~~~ 纯属谣言16位的话，int占用2个字节；32位的话4个字节，64位的话8个字节。代码： 全选
#include <malloc.h> int main() { malloc(sizeof(int)); return 0; }
所以，源程序同样，编译16/32/64位之后所占的内容是有区别的，而且64位会更加大。
AMD64机器 int仍然是4字节的
我的是AMD64系统+AMD64的GCC
还有 你提供的那段样本代码 根本不会造成内存泄露
不知道你看过Linux内核源码没有 2.6的内核 运行这段代码 都不会造成任何副作用
在进程结束时 调用_exit系统调用 陷入内核 并且内核会自动回收分配给进程的任何存储单元
一般int型所占长度是机器的自然字长。这个姑且不论，仅仅是指针从32位变到64位也会多占用内存的，所以这个是有可能的，关于这个段代码有无副作用根本没有意义去争论，哪个程序员会傻到写这样的东西？xhy 写了：你确定你试过?stlxv 写了：这很有可能，不过要针对多少位版本的程序来说，例如下面一段会导致内存泄露的程序：xhy 写了：另外，64位运行同样的程序，所需内存会增大。
~~~~~~~~~~~~~~~~~~~~~~~~~~~ 纯属谣言16位的话，int占用2个字节；32位的话4个字节，64位的话8个字节。代码： 全选
#include <malloc.h> int main() { malloc(sizeof(int)); return 0; }
所以，源程序同样，编译16/32/64位之后所占的内容是有区别的，而且64位会更加大。
AMD64机器 int仍然是4字节的
我的是AMD64系统+AMD64的GCC
还有 你提供的那段样本代码 根本不会造成内存泄露
不知道你看过Linux内核源码没有 2.6的内核 运行这段代码 都不会造成任何副作用
在进程结束时 调用_exit系统调用 陷入内核 并且内核会自动回收分配给进程的任何存储单元