重载运算符&&和

重载运算符&&和||(Overloading operator&& and || to create a class that saves dynamic logic)

我有一个从枚举创建的类，可以在将来的任何时候进行测试，返回bool是否通过，例如：

ConditionObject cnd(CondIsTuesday); door.setOpenCondition(cnd);

然后门有条件可以用来确定它的状态。

但是我希望现在重载&&和|| 此条件类的运算符，以便它们可以链接在一起并以正常布尔逻辑的预期方式工作。 例如，使以下可能：

ConditionObject cnd(ConditionObject(CondIsTuesday) || (ConditionObject(CondIsThursday) && ConditionObject(CondIsAfterEight))); door.openCondition(cnd);

现在门将在星期二或星期四之后开放。

我不确定描述问题的正确方法，如果已经存在，也难以搜索解决方案。 感谢您对此问题的任何帮助！

[编辑]我不认为我解释得很好，我不希望在创建对象时评估ConditionObject，而是将整个逻辑存储到最终的ConditionObject中，以便可以对其进行评估懒洋洋。

使用上面的第二个例子，如果我在星期一创建了cnd对象并且永远不会给门另一个条件，它将在周二开放，因为它给出的条件开始返回true。

I have a class that is created from an enum that can be tested at any point in the future returning a bool whether it passes, for example:

ConditionObject cnd(CondIsTuesday); door.setOpenCondition(cnd);

Then the door has a condition that it can use to determine its state.

However I wish to now overload the && and || operators for this condition class such that they can be chained together and work in the way expected with normal boolean logic. For example, making the following possible:

ConditionObject cnd(ConditionObject(CondIsTuesday) || (ConditionObject(CondIsThursday) && ConditionObject(CondIsAfterEight))); door.openCondition(cnd);

Now the the door will be open on tuesdays or thursdays after eight.

I wasn't sure of the correct way to describe the problem which also made it hard to search for a solution if one already existed. Thanks for any help with the problem!

[Edit] I don't think I explained it well enough, I don't want the ConditionObject to be evaluated at the time of the creation of the object but instead to store the entire logic into the final ConditionObject such that it can be evaulated lazily.

Using the second example above, If I created the cnd object on a monday and never give the door anouther condition, it will open come tuesday because the condition it was given started returning true.

最满意答案

“表达模板”可能对您有用。 这似乎是一个相当彻底的主题，但还有其他。 我对这个主题并不过分熟悉，但这应该是一个很好的谷歌搜索点。

基本思想是你需要一棵树，叶子是一个实际的条件，它们之间的分支是定义它们如何相互作用的运算符。 expresion模板就是这个树，你重载运算符来构建树。

然后，当你真的想知道你的门是否需要打开时，你走在树上，轮流检查每个条件，直到你得到你的答案。 像Tony提到的短路评估应该是自然而然的，因为你最终会回归内置的运营商。

"Expression Templates" might be of use to you. This seems to be a reasonably thorough take on the subject, but there are others. I'm not overly familiar with the subject, but that should be a good googling point.

The basic idea is that you want a tree, with the leafs being an actual condition, and the branches between them the operators that define how they interact. The expresion template is this tree, and you overload operators to build the tree.

Then, when you actually want to know if your door needs to open, you walk the tree, checking each condition in turn until you have your answer. Short-circuit evaluation [like Tony mentioned] should come naturally, since you ultimately fall back on the built in operators.