问题
I'm currently in the process of converting some uses of unsigned int to size_t in my a code base that I have been developing over the years. I understand the difference between the two and that for example unsigned int could be 32-bit while pointers and size_t could be 64-bit. My question is more about where I should use either one and what kind of convention people use for picking between the two.
It's quite clear that memory allocation should take size_t instead of unsigned int as an argument, or that container classes should use size_t for size and indexing like in STL. These are the common cases referred when reading about the benefits of size_t vs unsigned int. However, while working on the code base conversion I stumbled upon quite a few cases in gray areas where I'm not sure which one to use. For example if 4x4 matrix row/column index should be size_t for consistency regardless the index being in range [0, 3], or if screen/texture resolution should use size_t despite of being in range of few thousand, or in general if the reasonable number of objects is expected to be in the range of tens I should still use size_t for consistency.
What kind of coding conventions you use for picking between unsigned int and size_t? Should everything that's representing size (in bytes or objects), or index be always size_t regardless of the reasonably expected range? Is there some widely accepted size_t convention used in well-established libraries that I could follow?
回答1:
I think it's simple, although I welcome the slings and arrows.
size_t should be used if it describes something that has a size. (A count. A number of things)
回答2:
With a 32- to 64-bit port of some legacy code recently on my mind, the key characteristic of size_t in my mind is that it is always big enough to represent your whole address space.
Any other type you can name (including unsigned long) has the potential to put an artificial limit on your data structures at some point in the future. size_t (and its cousin ptrdiff_t) should be the default basis for data structure construction when you can't define a hard a priori upper bound on the domain.
回答3:
To me, the question whether you use an integer that is smaller than the architectural width, is the question whether you can prove that smaller size to be sufficient.
Take for example your 4x4 Matrix: Is there a theoretical reason why it must be 4x4 and not, say 5x5 or 8x8? If there is such a theoretical reason, I have no problem with a smaller integer type. If there is none, use size_t or another type that's at least as wide.
My reasoning is that fixed limits (and fixed integer sizes are just one way to introduce those) are generally sleeping bugs. Someone, someday will probably find some extreme use-case where the assumptions you made to fix the limit don't hold. So you want to avoid them wherever they might crop up. And since I generally don't bother to do a proof for a smaller size (because it's pointless regarding performance), I usually end up using full size integers.
来源：https://stackoverflow.com/questions/24226483/where-to-draw-the-line-between-size-t-and-unsigned-int