blocks|key|1201041|text|好吧，根据你引用的网页，函子没有多大优势(“操作人员可以欺骗我们的直觉，认为昂贵的操作是廉价的、内置的操作”)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1201042|我的感觉是，一个人应该努力使你尽可能地将一流的对象分类，对我来说，这意味着让他们理解尽可能多的操作人员。|1201043|我已经有一段时间没有写函子了，但是它看起来是这样的：|1201044|class+MyClass+{....}

class+LessThanMyClass+:+std:binary_function<MyClass,+MyClass,+bool>
{
++++public+bool+operator()(MyClass+lhs,+MyClass+rhs)+
++++{+++return+/*+determine+if+lhs+<+rhs+*/+;+}
}

vector<MyClass>+objs;
std::sort(objs.begin(),+objs.end(),+LessThanMyClass());|code-block|syntax|javascript|1201045|}|1201046|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Q|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|R|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

Well, according to the webpage you cite, there's not much advantage for functors ("[operators] can fool our intuition into thinking that expensive operations are cheap, built-in operations.")

My felling is that one should strive to make you classes first-class objects as much as possible, which, to me, means having them understand as many operators as sensible.

It's been a while since I written a functor, but it would look something like this:

<pre><code>class MyClass {....}

class LessThanMyClass : std:binary_function&lt;MyClass, MyClass, bool&gt;
{
 public bool operator()(MyClass lhs, MyClass rhs) 
 { return /* determine if lhs &lt; rhs */ ; }
}

vector&lt;MyClass&gt; objs;
std::sort(objs.begin(), objs.end(), LessThanMyClass());
</code></pre>

}

blocks|key|1201114|text|函子是一个具有operator+()的类。在这种情况下，该方法将接受被比较类型的两个参数，如果第一个参数小于第二个参数，则返回一个bool结果。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1201115|编辑:要在詹姆斯·柯伦所说的基础上构建，可以在类中定义函子。因此，例如：|1201116|class+MyClass
{
++++struct+LessThan+:+public+std::binary_function<MyClass,+MyClass,+bool>
++++{
++++++++bool+operator()(const+MyClass+&+first,+const+MyClass+&+second)+const
++++++++{
++++++++++++return+first.key+<+second.key;
++++++++}
++++};
};|code-block|syntax|javascript|1201117|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/183606/comparison-functor-types-vs-operator#183653^0|7|B|1T|4|0|5|6|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@$9|V|A|W|B|C]|$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Z|8|@]|D|@$9|10|A|11|1|12]]|E|$]]|$1|H|3|I|5|J|7|13|8|@]|D|@]|E|$K|L]]|$1|M|3|-4|5|6|7|14|8|@]|D|@]|E|$]]]|N|$O|$5|P|Q|R|E|$S|T]]]]

A functor is a class with an <code>operator ()</code>. In this case the method would take two parameters of the type being compared and return a <code>bool</code> result if the first is less than the second.

Edit: to build on what <a href="https://stackoverflow.com/questions/183606/comparison-functor-types-vs-operator#183653">James Curran</a> said, you can define your functor inside the class. So, for example:

<pre><code>class MyClass
{
 struct LessThan : public std::binary_function&lt;MyClass, MyClass, bool&gt;
 {
 bool operator()(const MyClass &amp; first, const MyClass &amp; second) const
 {
 return first.key &lt; second.key;
 }
 };
};
</code></pre>

blocks|key|863629|text|具有讽刺意味的是，函式还需要重写运算符(函数调用操作符-+operator+())，所以我不确定它们的意义是什么。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|863630|entityMap^0|T|B|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

Ironically, a functor also requires overriding an operator (the function call operator - <code>operator ()</code>), so I'm not sure what their point is.

blocks|key|1201149|text|除了最基本的类型之外，较少的操作并不总是琐碎的，甚至平等也可能因情况而异。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1201150|想象一下，一家航空公司想给所有乘客分配登机号码。这个数字反映了登机令(当然)。现在，是什么决定了谁先于谁？您可以采取客户注册的顺序--在这种情况下，少于操作的用户将比较签入时间。你也可以考虑顾客为他们的机票支付的价格--比现在的票价要低。|1201151|…诸若此类。总之，在operator+<类上定义一个Passenger是没有意义的，尽管它可能需要在一个排序的容器中有乘客。我认为这正是谷歌所警告的。|offset|length|style|CODE|1201152|entityMap^0|0|0|A|A|Q|9|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@$F|O|G|P|H|I]|$F|Q|G|R|H|I]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|K|$]]

Except for the more fundamental types, the less-than operation isn't always trivial, and even equality may vary from situation to situation.

Imagine the situation of an airline that wants to assign all passengers a boarding number. This number reflects the boarding order (of course). Now, what determines who comes before who? You might just take the order in which the customers registered – in that case, the less-than operation would compare the check-in times. You might also consider the price customers paid for their tickets – less-than would now compare ticket prices.

… and so on. All in all, it's just not meaningful to define an <code>operator &lt;</code> on the <code>Passenger</code> class although it may be required to have passengers in a sorted container. I think that's what Google warns against.

blocks|key|1201168|text|通常，定义operator<更好、更简单。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1201169|要使用函子的情况是需要多种方法来比较特定的类型。例如：|1201170|class+Person;

struct+CompareByHeight+{
++++bool+operator()(const+Person+&a,+const+Person+&b);
};

struct+CompareByWeight+{
++++bool+operator()(const+Person+&a,+const+Person+&b);
};|code-block|syntax|javascript|1201171|在这种情况下，可能没有一种很好的“默认”方法来比较和排序人员，因此不定义operator<和使用函子可能会更好。你也可以说，一般人是按身高排序的，所以operator<只叫CompareByHeight，任何需要按体重排序的人都必须显式地使用CompareByWeight。|1201172|通常情况下，问题在于定义函子是由类的用户决定的，因此当类需要在有序容器中使用时，您往往会得到对同一事物的许多重新定义。|1201173|entityMap^0|5|9|0|0|0|10|9|23|9|2E|F|3D|F|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@$9|T|A|U|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|V|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|W|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|X|8|@$9|Y|A|Z|B|C]|$9|10|A|11|B|C]|$9|12|A|13|B|C]|$9|14|A|15|B|C]]|D|@]|E|$]]|$1|O|3|P|5|6|7|16|8|@]|D|@]|E|$]]|$1|Q|3|-4|5|6|7|17|8|@]|D|@]|E|$]]]|R|$]]

Generally, defining <code>operator&lt;</code> is better and simpler.

The case where you would want to use functors is when you need multiple ways of comparing a particular type. For example:

<pre><code>class Person;

struct CompareByHeight {
 bool operator()(const Person &amp;a, const Person &amp;b);
};

struct CompareByWeight {
 bool operator()(const Person &amp;a, const Person &amp;b);
};
</code></pre>

In this case there may not be a good "default" way to compare and order people so not defining <code>operator&lt;</code> and using functors may be better. You could also say that generally people are ordered by height, and so <code>operator&lt;</code> just calls <code>CompareByHeight</code>, and anyone who needs Person's to be ordered by weight has to use <code>CompareByWeight</code> explicitly.

Often times the problem is that defining the functors is left up to the user of the class, so that you tend to get many redefinitions of the same thing, whenever the class needs to be used in an ordered container.

blocks|key|1201212|text|我可能不会走到谷歌风格的指南那么远。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1201213|我认为，当您重载operator<和operator==时，您将对该类型的每次使用做出决定，而函子类型仅适用于该集合。|offset|length|style|CODE|1201214|如果您唯一需要比较器的东西是将项放入集合中，那么最好有一个专门针对该上下文的函数，而不是适用于所有上下文的运算符。|1201215|你可能想按时间顺序对订单进行排序，但一般来说，用它们的总价来比较它们是有意义的。如果我们让operator<过载来比较日期，以便将它们加载到一个集合中，那么我们就引入了另一个客户可能滥用我们的operator<的风险，他们可能会认为这样做比较了总价格。|1201216|entityMap^0|0|8|9|I|A|0|0|19|9|2O|9|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@$D|P|E|Q|F|G]|$D|R|E|S|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@$D|V|E|W|F|G]|$D|X|E|Y|F|G]]|9|@]|A|$]]|$1|L|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|M|$]]

I probably wouldn't go as far as the Google style guide.

I think that what they are getting at is that when you overload <code>operator&lt;</code> and <code>operator==</code>, you are making a decision for every use of the type, while the functor types only apply to that collection.

If the only thing you need the comparators for is to put the item in a collection, then it's better to have a function specifically for that context rather than the operators that would apply in all contexts.

You may want to sort purchase orders chronologically, but in general, it would make sense to compare them by their total price. If we overload <code>operator&lt;</code> to compare dates so that we can load them into a collection, we are introducing the risk that another client may misuse our <code>operator&lt;</code> which they may think compares the total prices.

blocks|key|863682|text|我认为不定义operator<背后的信息是，排序是集合的属性，而不是对象的属性。相同对象的不同集合可能有不同的顺序。因此，在指定集合的类型时，应该使用单独的函子，而不是operator<。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|863683|然而，在实践中，许多类可能具有自然排序，这是应用程序中集合中使用的唯一排序。在其他情况下，排序甚至可能与应用程序无关，只与集合相关，以便它稍后可以找到项。在这些情况下，定义operator<是非常有意义的。|863684|记住，当我们设计对象模型时，我们只是在模拟现实世界的一个子集。在现实世界中，可能有许多不同的方法来对同一类的对象进行排序，但在我们工作的应用程序域中，可能有一种方法是相关的。|863685|如果代码发展到需要与第一个同样相关的第二个排序，则应该重构类以删除operator<，并将这两个排序函数放在单独的函子中。这表明，没有任何一种排名比其他排名更重要。|863686|关于算术运算符，除非您正在实现算术类型，否则不应该重载这些运算符。|863687|当然，每条规则都有例外。如果你不知道你是否应该做一个例外，你可能不应该。经验将是你的指南。|863688|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

I think the message behind not defining operator&lt; is that ordering is a property of the collection, not of the object. Different collections of the same objects may have different orderings. So you should use a separate functor used when specifying the type of the collection rather than operator&lt;.

In practice though, a lot of your classes may have a natural ordering and that is the only ordering used in collections in your application. In other cases, the ordering may not even be relevant to the application, just the collection so it can find items later. In these cases, it makes perfect sense to define operator&lt;.

Remember, when we're desiging object models, we're only modelling a subset of the real world. In the real world there may be umpteen different ways to rank objects of the same class, but in the application domain in which we are working there may be one that is relevant.

If code evolves to need a second ordering that is just as relevant as the first, the class should be refactored to remove operator&lt; and to place both ranking functions in separate functors. This shows the intent that no one ranking is more important than the others.

With regard to arithmetic operators, you should not overload these unless you are implementing an arithmetic type.

Of course, there are exceptions to every rule. If you don't know whether or not you should be making an exception, you probably should not. Experience will be your guide.

In the <a href="http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml" rel="noreferrer">Google C++ Style Guide</a>, the <a href="http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Operator_Overloading" rel="noreferrer">section on Operator Overloading</a> recommends against overloading any operators ("except in rare, special circumstances"). Specifically, it recommends:

<blockquote>
 In particular, do not overload
 <code>operator==</code> or <code>operator&lt;</code> just so that
 your class can be used as a key in an
 STL container; instead, you should
 create equality and comparison functor
 types when declaring the container.
</blockquote>

I'm a little fuzzy on what such a functor would look like, but my main question is, why would you want to write your own functors for this? Wouldn't defining <code>operator&lt;</code>, and using the standard <code>std::less&lt;T&gt;</code> function, be simpler? Is there any advantage to using one over the other?

Comparison Functor Types vs. operator<

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

在中，建议不要超载任何操作符(“除非在罕见的特殊情况下”)。具体而言，委员会建议：特别是，不要重载operator==或operator<，这样您的类就可以作为STL容器中的键使用；相反，在声明容器时，应该创建相等和比较函式类型。我有点模糊这样的函子会是什么样子，但我的主要问题是，你为什么要为这个写你自己的函子？定义o...

问函子类型与operator<的比较
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问函子类型与operator<的比较EN