考虑到这个数字可能真的很大，使用它是否安全unsigned long？
FWIW，我将 apache 日志中的所有微秒加起来，因此这个数字会变得非常大。
问问题
2562 次
8 回答
9
鉴于您可以在 32 位平台上存储的最大值unsigned long约为 4G，这些 4G 微秒转换为仅 71 分钟。
在 64 位平台上（注意在 Windows 上 long 始终是 32 位，即使在 Windows 64 位上也是如此），那么您最多可以计算 4G 乘以 71 分钟的微秒。这是巨大的：大约 5800 个世纪。
答：如果你unsigned long是 64 位的，没关系。
于 2013-06-05T15:39:42.440 回答
6
使用标准C存储“非常大”的数字的最佳方法是unsigned long long int：
- unsigned long long int
ULLONG_MAX 类型对象的最大值 18446744073709551615 // 2 64 - 1
这是在 C99+ 标准中定义的。如果您愿意/想要超越 C 可以做的事情，还有其他扩展可以查看，首先想到的是GNU MP Bignum 库。
我认为您应该考虑的第三种选择是将其分解为微秒和秒，就像对结构gettimeofday()所做的那样timeeval。这样你就不必进入荒谬的数字。如果您想在几微秒内查看数据，您始终可以自己进行转换。
于 2013-06-05T15:43:31.127 回答
2
要看。如wikipedia上所述，anunsigned long保证至少为 32 位，但我想这可能取决于您的机器。使用 32 位，您可以表示大到 2^32 = 4294967296 的数字。4294967296 微秒是 4294 秒或 1 小时多一点。
你需要更多吗？如果这样做，请考虑使用unsigned long long保证为 64 位的，但它是 C99。否则，您始终可以将秒数单独存储在另一个变量中，例如 timeval 结构。
于 2013-06-05T15:44:09.800 回答
2
您可以使用无符号长整数。大小为 0 到 4294967295 字节
于 2013-06-05T19:03:26.843 回答
1
一个 32 位无符号整数将给您大约 1 小时 11 分钟，以微秒计：
4,294.967295 seconds
另一方面，一个 64 位无符号整数会给你超过 50 万年。
于 2013-06-05T15:42:04.640 回答
1
unsigned long integer is the best option to store big size data.
于 2013-06-05T19:31:08.527 回答
0
32bit肯定会太小，unsigned long long看来是正确的选择，保证至少64bit。或者使用unit64_tin <inttypes.h>，理论上更便携。
大概5亿年，应该够了。^_^
于 2013-06-05T15:40:55.773 回答
0
unistd.h声明useconds_t。
更新指的是问题的正文而不是其标题：
使用 计算秒数，time_t然后使用 . 以微秒为单位存储余数useconds_t。这使您的资源 100% 可移植。
更新 2
我刚刚发现我最近的 Debian 声明suseconds_t为long int.
于 2013-06-05T16:01:28.970 回答