为什么会首选uint32_t而不是uint_fast32_t? [英] Why would uint32_t be preferred rather than uint_fast32_t?

问题描述

似乎 uint32_t 比 uint_fast32_t 更为普遍(我意识到这是轶事证据).不过，这对我来说似乎违反直觉.

几乎总是当我看到一个实现使用 uint32_t 时，它真正想要的是一个整数，最多可以容纳4,294,967,295(通常在65,535和4,294,967,295之间的下限).

然后使用 uint32_t 似乎很奇怪，因为不需要精确地32位" 保证，并且最快的可用时间> = 32位"保证 uint_fast32_t 似乎是正确的主意.而且，尽管通常实现了 uint32_t ，但实际上并不能保证其存在.

那么，为什么首选 uint32_t ?它是众所周知的还是相对于其他而言具有技术优势?

解决方案

uint32_t 确保在任何支持它的平台上具有几乎相同的属性. ¹

uint_fast32_t 几乎无法保证它在不同系统上的行为.

如果您切换到 uint_fast32_t 具有不同大小的平台，则必须重新测试和验证所有使用 uint_fast32_t 的代码.所有稳定性假设都将成为现实.整个系统将以不同的方式工作.

编写代码时，您甚至可能无法访问大小为32位的 uint_fast32_t 系统.

uint32_t 不会有所不同(请参见脚注).

正确性比速度更重要.因此，过早正确性比过早优化是更好的计划.

如果我正在为 uint_fast32_t 为64位或更多位的系统编写代码，则可能会同时测试我的代码并使用它.限制需求和机会，这样做是一个糟糕的计划.

最后， uint_fast32_t 存储任何时间长度或实例数可能会比 uint32 慢，这仅仅是由于高速缓存大小问题和内存带宽.如今，计算机受内存限制的频率要比受CPU约束的频率高得多，并且 uint_fast32_t 可能会更快地隔离，但在考虑了内存开销之后却没有.

---

¹ 正如@chux在评论中指出的那样，如果 unsigned 大于 uint32_t ，则对 uint32_t 经过通常的整数促销，如果没有，则保持为 uint32_t .这可能会导致错误.世上没有完美的事.

It seems that uint32_t is much more prevalent than uint_fast32_t (I realise this is anecdotal evidence). That seems counter-intuitive to me, though.

Almost always when I see an implementation use uint32_t, all it really wants is an integer that can hold values up to 4,294,967,295 (usually a much lower bound somewhere between 65,535 and 4,294,967,295).

It seems weird to then use uint32_t, as the 'exactly 32 bits' guarantee is not needed, and the 'fastest available >= 32 bits' guarantee of uint_fast32_t seem to be exactly the right idea. Moreover, while it's usually implemented, uint32_t is not actually guaranteed to exist.

Why, then, would uint32_t be preferred? Is it simply better known or are there technical advantages over the other?

解决方案

uint32_t is guaranteed to have nearly the same properties on any platform that supports it.¹

uint_fast32_t has very little guarantees about how it behaves on different systems in comparison.

If you switch to a platform where uint_fast32_t has a different size, all code that uses uint_fast32_t has to be retested and validated. All stability assumptions are going to be out the window. The entire system is going to work differently.

When writing your code, you may not even have access to a uint_fast32_t system that isn't 32 bits in size.

uint32_t won't work differently (see footnote).

Correctness is more important than speed. Premature correctness is thus a better plan than premature optimization.

In the event I was writing code for systems where uint_fast32_t was 64 or more bits, I might test my code for both cases and use it. Barring both need and opportunity, doing so is a bad plan.

Finally, uint_fast32_t when you are storing it for any length of time or number of instances can be slower than uint32 simply due to cache size issues and memory bandwidth. Todays computers are far more often memory-bound than CPU bound, and uint_fast32_t could be faster in isolation but not after you account for memory overhead.

---

¹ As @chux has noted in a comment, if unsigned is larger than uint32_t, arithmetic on uint32_t goes through the usual integer promotions, and if not, it stays as uint32_t. This can cause bugs. Nothing is ever perfect.

这篇关于为什么会首选uint32_t而不是uint_fast32_t?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！