为什么将 int 格式化为 6*1000*1000 而不是 6000000 [重复]答案

【问题标题】：why formatting an int as 6*1000*1000 and not 6000000 [duplicate]为什么将 int 格式化为 6*1000*1000 而不是 6000000 [重复]
【发布时间】：2017-08-09 05:12:54
【问题描述】：

我正在阅读用 c 编写的中间件代码，他们在代码中编写了以下代码：

usleep(6*1000*1000);

所以我的问题是：

这样写有什么原因吗？为什么不直接写 6000000？做这个乘法对程序的性能有什么影响吗？

【问题讨论】：

或者为什么不直接写sleep(6);，它也传达了“6 秒”而没有任何可读性问题。
您能立即分辨出6000000 和60000000 和600000 之间的区别吗？阅读大量代码时，有时很难确切地看到存在多少个零。
比这样的废话更好更安全的技巧：(int)(6.0*10e6)
@Lundin：您的(int)(6.1*10e6) 建议存在致命缺陷，因为您在需要 6 的情况下使用 6.1，并且睡眠时间是所需时间的 10 倍。这两个都表明它绝不是更好和更安全的。 —— Lundin 设法在时间限制结束之前纠正了他的 cmets（但不是一个数量级的关闭：6.0*1E6 或 6.0*1.0E6 就可以了）。;
6*1000*1000 与 6000000 的问题在于类型。考虑6*1000*1000*1000 (int math) vs. 6000000000 vs. 6LL*1000*1000*1000 (long long math)

标签： c syntax formatting int

【解决方案1】：

它只是使源代码更易于阅读。加上乘法，这个数字显然是六百万。

当它评估为一个常量时，编译器将在编译时评估该常量，编译后的代码不会有任何差异。

【讨论】：

乘法可能会溢出，具体取决于int 范围和使用的数字。（希望会出现警告）没有乘法的常数没有这个问题。

【解决方案2】：

很可能，这样做是为了便于阅读。

查看代码中的6000000，您可能不会立即看到有多少个零。此值与60000000 或600000 之间的视觉区别不是很大。通过拆分，它更易于查看。

任何体面的编译器都应该在编译时计算6*1000*1000，所以应该不会影响性能。

【讨论】：

注意：对于 16 位 int，6000000 与 6*1000*1000 不同。

【解决方案3】：

usleep() 期望提供的参数以“微秒”为单位。

这是从微秒到秒的视觉转换，对预期的代码没有影响，因为任何半体面的编译器都会在编译时计算。

【讨论】：

"对预期的代码没有影响" --> 但要注意 int 溢出，这确实发生在 16 位 int 和 6*1000*1000 上。