size_t是一个无符号整数类型，由(例如(sizeof返回。因此，我可以向其中投射unsigned long吗？可能会出现什么问题？我应该使用static_cast还是reinterpret_cast，或者其他？
编辑：
我想把一个字符串转换成unsigned long，然后将其转换为size_t:
size_t StringHandling::ConvertSize_T (std::string& input, int base)
{
return static_cast<size_t>(std::stoul(input, 0, base));
}
您能安全地将std::size_t转换为unsigned long吗
一般…否。
如果unsigned long的宽度与系统上的std::size_t的宽度相同，那么您可以使用一个简单的static_cast。但为什么要冒险呢？如果没有，而且这在当今存在的系统上也绝非不可能，那么您可能会截断一半您的价值空间——如果您从64位到32位，则可能会损失1850亿、四百四十六万亿、七百四十四万亿的价值！！
如果从决定需要该类型来表示其结果的所有可能值的函数中获得std::size_t，请保留std::size_t。
您能安全地将unsigned long投射到std::size_t吗
当然。从技术上讲，我不认为后一个有任何理由比前一个更宽(甚至至少和前一个一样宽((它只需要至少16位宽(，但你很难找到任何不是这样的系统。
你能安全地混合std::stoul和std::size_t吗
这取决于您的项目需求。如上所述，将std::stoul的结果转换为std::size_t可能是好的。
但是，std::stoul本身呢？您是否希望字符串包含适合std::size_t但不适合unsigned long的数值？如果是这样的话，那么这里的字符串解析是错误的，而不是强制转换，您需要找到一种更合适的方法来从流中提取这么大的数字。
tl；dr:尽量不要混用类型。计算出输入的预期数字范围，相应地选择一个合适的类型，然后在整个管道中使用它。
如果你的意思是以理论的、语言律师的方式，那么答案是否定的：
根据1999年ISO C标准(C99(，
size_t是一种至少为16位的无符号整数类型(请参见7.17和7.18.3节(
C99标准的所有保证是它至少是16位类型。
然而，在现代Intel/ARM体系结构的现实世界中，size_t通常是本机寄存器大小，因此32位体系结构上为32位，64位体系结构中为64位。您应该始终能够将int存储在size_t中，但不能反过来。
我应该使用静态或重新解释强制转换，还是其他方式？
此强制转换是一个静态强制转换，reinterpret用于重新解释指向不同不相关类型的指针。