存在超载一元运算符的合理原因？
好吧，我已经受到启发，做一些头部冲刺 。 似乎超载operator&导致不less的痛苦。
什么合法的情况下超载呢？
（不能说我曾经这样做过….）
我似乎记得像一个智能指针类的operator&因为它想要返回所包含的指针的地址，而不是智能指针对象的地址。 不记得我在哪里看到它，或者当时看起来是个好主意。
啊哈，记得：微软的CComPtr 。
编辑：为了推广，在下列情况下可能是有意义的：
- 你有一个伪装成其他物体的物体。
- 这个对象可以获得一个指向它伪装成的东西的指针。
返回除了合法指针以外的任何内容都将违反最不惊讶的原则 。
重载一元&使你的对象像一个参考行为（在这方面）。
我敢肯定，试图提供内置引用的替代方法是个愚蠢的错误，特别是因为引用不是C ++中的对象，而且它们没有自己的地址。 您的用户定义types的实例不可避免地是对象，并且确实有地址，即使您禁用获取该地址的正常方式。 所以它永远不是一个完美的模仿。
但是，人们非常热衷于用户定义的指针select，所以我可以看看有人可能想要尝试它。 我不确定他们是否会避免创build一种types的（错误的）行为方式，使用户希望他们没有打扰。
用lambda占位符符号表示&操作时很有用，例如&_1[_2] 。
四年后，又一个答案。
我已经看到的另一个用途是当你捎带C ++语言，但定义自己的语义。 最好的例子：Boost.Spirit。
Boost.Spirit，尤其是用于parsing的Qi，在parsing器上重载运算符，以提供用于指定任意parsing器对象的类EBNF语法。 特别是，一元&运算符被重载以提供And-Predicateparsing器 。
和谓语parsing器（＆a）
描述
句法谓词在评估另一个生产之前声明一个满足的条件语法。 类似于语义谓词eps，句法谓词不消耗任何input。 和谓词＆a是一个积极的句法谓词，只有当谓词匹配时才返回一个零长度的匹配。
用法示例：
基本的预见示例：确保最后一个字符是分号，但不要使用它，只需查看下一个字符：
test_phrase_parser("Hello ;", lit("Hello") >> &lit(';'), false);
所以简而言之，这里的一元&这里根本没有关系， 它具有适用于Qiparsing器对象的特定于域的语义。
我已经在生成LLVM代码的DSL的上下文中做到了这一点。 一个例子将说明。 说x和y是值（即typesvalue对象）。 然后，expression式x+y将ADD指令发送到某个代码stream中。 非常明智的是，expression式&x发出一条指令来取x的地址。
一旦我习惯覆盖operator＆（而不改变它的行为）作为类的私有，以防止偶尔创build在堆栈中创build的对象的智能指针。 仍然不确定这是否真的是个好主意…
您可以重载地址运算符以使其私有。 这对于实施某种接力传球scheme可能是有用的，其中接力棒的地址不能被采取。 如果警棍的构造函数是隐藏的，这可以保持警棍的范围不透气。
