通过C++20三元比较，更多的沉默行为改变

Question

令我吃惊的是，我遇到了另一个障碍，比如C++20行为破坏了现有代码的相等运算符？。

考虑使用一个简单的不区分大小写的键类型，例如，std::set或std::map:

// Represents case insensitive keys
struct CiKey : std::string {
    using std::string::string;
    using std::string::operator=;

    bool operator<(CiKey const& other) const {
        return boost::ilexicographical_compare(*this, other);
    }
};

简单测试：

using KeySet   = std::set<CiKey>;
using Mapping  = std::pair<CiKey, int>; // Same with std::tuple
using Mappings = std::set<Mapping>;

int main()
{
    KeySet keys { "one", "two", "ONE", "three" };
    Mappings mappings {
        { "one", 1 }, { "two", 2 }, { "ONE", 1 }, { "three", 3 }
    };

    assert(keys.size() == 3);
    assert(mappings.size() == 3);
}

>

使用C++17，两个断言都传递（编译器资源管理器）。

切换到C++20，第二个断言失败（编译器资源管理器）

output.s：./example.cpp:28:int main():Assertion`mappings.size()==3'失败。

一个明显的解决办法是在C++20模式下有条件地提供运算符<=>：编译资源管理器

#if defined(__cpp_lib_three_way_comparison)
    std::weak_ordering operator<=>(CiKey const& other) const {
        if (boost::ilexicographical_compare(*this, other)) {
            return std::weak_ordering::less;
        } else if (boost::ilexicographical_compare(other, *this)) {
            return std::weak_ordering::less;
        }
        return std::weak_ordering::equivalent;
    }
#endif

让我吃惊的是，我遇到了另一个中断更改的情况--在这种情况下C++20在没有诊断的情况下更改了代码的行为。

在我阅读std::tuple::operator<时，它应该起作用了：

3-6）通过运算符<对LHS和RHS进行词典比较，即比较第一个元素（如果它们等价），比较第二个元素（如果它们等价），比较第三个元素，以此类推。对于非空元组，(3)等价于

if (std::get<0>(lhs) < std::get<0>(rhs)) return true;
if (std::get<0>(rhs) < std::get<0>(lhs)) return false;
if (std::get<1>(lhs) < std::get<1>(rhs)) return true;
if (std::get<1>(rhs) < std::get<1>(lhs)) return false;
...
return std::get<N - 1>(lhs) < std::get<N - 1>(rhs);

我知道从技术上讲，这些从C++20开始就不适用了，取而代之的是：

通过合成的三元比较（见下文）对LHS和RHS进行词典比较，即比较第一个元素（如果它们等价），比较第二个元素（如果它们等价），比较第三个元素，依此类推

连同

<、<=、>、>=和！=运算符分别由运算符<=>和运算符==合成。（自C++20起）

问题是,

>

我的类型没有定义运算符<=>或运算符==,

正如这个答案所指出的，另外提供运算符<会很好，并且应该在计算诸如a 这样的简单表达式时使用。

1. C++20中的行为更改是否正确/是故意的？
2. 是否应进行诊断？
3. 我们可以使用其他工具来发现像这样的无声破坏吗？在元组/对中扫描整个代码库以了解用户定义类型的使用情况，感觉并不能很好地缩放。
4. 除了元组/对之外，是否还有其他类型可以显示类似的更改？




Answer 1

啊！@说书人用他们的评论钉死了：

“My type不定义运算符<=>也不定义运算符==”--但std::string定义了运算符，这使它成为D[e]向基转换的候选项。我相信所有支持比较的标准库类型都对其成员进行了彻底检查。

实际上，一个更快的解决办法是：

#if defined(__cpp_lib_three_way_comparison)
    std::weak_ordering operator<=>(
        CiKey const&) const = delete;
#endif

成功了！编译器资源管理器

更好的解决方案，正如StoryTeller的第二条评论所暗示的：

我想非虚拟析构函数不再是避免从标准库容器继承的唯一有力理由：/

将避免这里的继承：

// represents case insensiive keys
struct CiKey {
    std::string _value;

    bool operator<(CiKey const& other) const {
        return boost::ilexicographical_compare(_value, other._value);
    }
};

当然，这需要对使用代码进行（一些）下游更改，但它在概念上更纯净，并且避免了将来这种“标准蠕变”。

编译器资源管理器

#include <boost/algorithm/string.hpp>
#include <iostream>
#include <set>
#include <version>

// represents case insensiive keys
struct CiKey {
    std::string _value;

    bool operator<(CiKey const& other) const {
        return boost::ilexicographical_compare(_value, other._value);
    }
};

using KeySet   = std::set<CiKey>;
using Mapping  = std::tuple<CiKey, int>;
using Mappings = std::set<Mapping>;

int main()
{
    KeySet keys { { "one" }, { "two" }, { "ONE" }, { "three" } };
    Mappings mappings { { { "one" }, 1 }, { { "two" }, 2 }, { { "ONE" }, 1 },
        { { "three" }, 3 } };

    assert(keys.size() == 3);
    assert(mappings.size() == 3);
}

我们怎样才能诊断出这样的问题。它们是如此微妙，以至于可以逃避代码审查。这种情况由于标准C++已经有20年的历史而变得更加严重，在这种情况下，标准C++的工作非常好，而且可以预测。

我想作为旁白，我们可以预期任何“提升”运算符（考虑std：：variant/std：：optional）在与过多继承标准库类型的用户定义类型一起使用时都有类似的缺陷。

Answer 2

基本的问题来自这样一个事实：您的类型不连贯，并且标准库直到C++20才调用您。也就是说，你的类型总是有点破碎，但事情的定义足够狭隘，你可以逃脱它。

您的类型被破坏了，因为它的比较运算符没有意义。它通告它是完全可比的，定义了所有可用的比较运算符。发生这种情况是因为您公开继承了std::string，因此您的类型通过隐式转换到基类来继承那些运算符。但是，这组比较的行为是不正确的，因为您只替换了其中一个比较，而这个比较与其他的比较不一样。

由于行为是不一致的，一旦C++真的关心你的一致性，可能会发生什么事情就等着你去抓了。

C++20中的行为改变是正确的/故意的吗？

那要看你说的“故意”是什么意思了。你的类型总是有这个问题；只是它在C++20中很重要。或者换一种说法，C++20比以前的版本更注重比较的一致性。

如果您为类型提供了完整的比较运算符，就不会有这个问题。所以从这个角度来看，C++20的行为是好的；是你的类型错了。

应该有诊断吗？

问题是您对操作符的实现不一致。没有概念可以检测到这一点。这是你做出的承诺。

我们能用其他的工具来发现像这样的无声破坏吗？

解决这一问题的最佳方法是找到实现一组不完整的比较运算符的所有类型，然后完成它们的实现。这在工具中不容易做到，因为它们可以从类型外部定义。