c++ - std::string::npos == -1 总是为真吗？

Question

标题相对不言自明。我认识到与其他答案的相似性，但所有这些都有不同的运算符安排(因此有不同的转换规则)。所以我需要一个可以澄清这个特殊情况的答案。

如果有人能指出解释这一点的标准部分，我会很乐意投票并接受答案。

Answer 1

不，这并不总是正确的。然而，它比乍看起来要复杂一些:

一开始，让我们看看是什么std::string是 (21.3/1):

The header <string> defines the basic_string class template for manipulating varying-length sequencesof char-like objects and four typedefs, string, u16string, u32string, and wstring, that name the specializationsbasic_string<char>, basic_string<char16_t>, basic_string<char32_t>, and basic_string<wchar_t>, respectively.

从 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 , 而右侧是一个整数文字，类型为 int ，当这样写时(没有进一步的限定词)。

结果是true如果size_t至少和int一样大(对于标准狂热者:具有大于或等于 4.13 中定义的整数转换等级)。否则，左侧 将提升为 int , 引起类似 0xFFFF == -1 的比较(对于 size_t 是 uint16_t 和 int 有 32 位)，这是 false .

请注意，虽然 16 位系统本身不再很常见(除了一些非常小的残余)，int不受标准限制为 32 位。以 x86_64 为目标的编译器 64位 size_t和 128 位 int在技​​术上是合规的。

所有引用均来自 C++11 标准 (ISO/IEC 14882:2011)。