使用-1作为unsigned（size_t）types的标志值
我使用-1作为返回types为size_t（无符号types）的函数的标志值。
我一开始并没有注意到，特别是因为它没有在我的代码中造成任何错误（我用x == -1来检查它，而不是x <0）。
有没有什么微妙的原因，我不应该离开它？ 什么时候这可能会出乎意料？ 这是常用的吗？
ptrdiff_t不太常见，需要更长的时间才能完成，反正它不是真正合适的types，因为函数返回一个数组中的索引。
-1将始终转换为最大无符号值，这是由于第4.7节积分转换 ：
如果目标types是无符号的，则结果值是与源整数相等的最小无符号整数（模2n，其中n是用于表示无符号types的位数）。 [注意：在二进制补码表示中，这种转换是概念性的，位模式没有变化（如果没有截断）。 – 注意]
C99的相同报价将从6.3.1.3 ：
否则，如果新types是无符号的，则通过重复地增加或减去新types中能够表示的最大值之一来转换该值，直到该值在新types的范围内。 49）
所以我们结束了：
-1 + (UMAX + 1)
这是：
UMAX
试图想到这种方式可能会出错，我意识到调用函数可能会隐式地将返回值转换为更大的types（即无符号整型为无符号长整型）。 然后检查值== -1是否为假。
更安全的选项是明确使用size_t.max作为标记值。 在签名和未签名types之间切换时，我总是感到不舒服。 有时候我觉得更合理的做法是只做一切签名（就像Java一样）。
显而易见的警告在于一组尺寸等于可能的最大尺寸的元件。 在实践中发生这种情况的可能性和可用性实际上是造成您的问题的原因是微不足道的。
如果你看看C ++的std::string类，你会注意到static std::string::npos数据成员被定义为正好-1转换为std::string::size_type （这真的只是std::size_t这使得这种“技术”具有优先感，这使得它能够满足“至less令人惊讶的原则”，这一直是一件好事。
现在，像这样的比较直接使用-1是在惹麻烦。 你应该像在std::string情况下一样，确保这个值有一个可访问的名字，这将确保它的特殊含义。 不幸的是，C ++types的系统对于防止用户自己砸死脚下来说并不够严格，但至less有一个坚持logging下来的最佳实践的用户不会想到有不同的做法。
