标题是相对不言自明的。我认识到与其他答案的相似之处，但是所有答案的运算符排列都不同（因此，转换规则也不同）。因此，我需要一个可以澄清这种特殊情况的答案。
如果有人可以指出标准中解释这一点的部分，我很乐意投票并接受答案。
不，并非总是如此。但是，乍一看它要复杂一些：
首先，让我们看看std::string（21.3 / 1）：
头
<string>定义了basic_string用于操纵焦炭状物体和四个类型定义，的可变长度的序列类模板string，u16string，u32string，和wstring，该名称的特化basic_string<char>，basic_string<char16_t>，basic_string<char32_t>，和basic_string<wchar_t>，分别。
从21.4 / 5开始：
template<class charT, class traits = char_traits<charT>, class Allocator = allocator<charT> > class basic_string { typedef typename allocator_traits<Allocator>::size_type size_type; static const size_type npos = -1; // [other members omitted] };
请注意，虽然使用npos进行了初始化-1，但其类型取决于Allocator::size_type，这意味着在没有进一步知识的情况下，我们无法简单地假设string::npos == -1它将进行编译。
现在，string使用默认分配器（毕竟模板参数在标准库提供的typedef中具有默认值），让我们检查20.6.9：
typedef size_t size_type;
现在，我们基本上可以将问题重写为：size_t(-1) == -1。现在发生的情况取决于子表达式的类型：当这样写时size_t，左手边显然是type ，而右手边是整数常量，它有type int（没有其他限定符）。
结果是trueifsize_t至少等于int（对于标准狂热者：具有更大的整数转换等级，如4.13所定义）。否则，左手侧将得到提升到int，导致像对比0xFFFF == -1（对于size_t作为uint16_t和int具有32位），这是false。
请注意，尽管16位系统本身已经不再是非常普遍的了（除了一些外形很小的残余物），int但标准并不仅限于32位。以64bitsize_t和128位int为目标的x86_64的编译器在技术上将合规。
所有引用均来自C ++ 11标准（ISO / IEC 14882：2011）。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句