c – std :: map要求的键(设计决策)

当我做一个std :: map< my_data_type,mapped_value>时,我期望的是my_data_type有自己的运算符< lt.

struct my_data_type
{
    my_data_type(int i) : my_i(i) { }

    bool operator<(const my_data_type& other) const { return my_i < other.my_i; }

    int my_i;
};

原因是您可以导出运算符>和operator ==来自operator< b < a意味着> b,所以有运算符>. ！(a< b)&& ！(b

operator== is inevitable for std::map::find()

这是你错误的地方.地图不使用operator ==,根本不是“不可避免的”.对于地图的目的,两个密钥x和y被认为是等效的,如果！(x< y)&& (y ,默认情况下使用operator<但是,如果您为KeyType专门使用std :: less,那么您不需要定义运算符<,并且如果为地图指定了不同的比较器,则它可能与操作符<或std :: less< KeyType&gt ;.所以我说过x以上,真的是cmp(x,y),其中cmp是严格的弱序. 这种灵活性是为什么不将operator ==拖到它中的另一个原因.假设KeyType是std :: string,并指定您自己的比较器,它可以实现特定于区域设置的不区分大小写的排序规则.如果map使用operator ==在某些时候,那么完全忽略这样一个事实,即只有通过大小写不同的字符串才能算作相同的键(或者在某些语言中)：其他差异被认为对排序规则没有影响.因此,平等比较也必须是可配置的,但程序员只能提供一个“正确的”答案.这不是一个好的情况,你永远不希望你的API提供一些看起来像一个定制点的东西,但实际上并不是这样. 此外,这个概念是,一旦你排除了比您要搜索的关键字小的树部分,以及键的小于该部分的树,那么剩下的就是空(否匹配找到)或者其中有一个键(匹配找到).所以,你已经使用当前的<键然后键<目前,没有别的选择,只有等价.情况正是：

if (search_key < current_element)
    go_left();
else if (current_element < search_key)
    go_right();
else
    declare_equivalent();

你建议的是：

if (search_key < current_element)
    go_left();
else if (current_element < search_key)
    go_right();
else if (current_element == search_key)
    declare_equivalent();

这显然是不需要的.事实上,这是你的建议效率低下！

点击查看更多相关文章

转载注明原文：c – std :: map要求的键(设计决策) - 代码日志

解决方法

operator== is inevitable for std::map::find()

这是你错误的地方.地图不使用operator ==,如果！(x< y)&& (y

上一篇：使用gdb跳到下一个“指令”下一篇：c和LD_PRELOAD.打开和open64调用被

c – std :: map要求的键(设计决策)

解决方法

相关推荐