Okay, I've been inspired to do some head punching. Seems like overloading
operator& leads to not a small amount of pain.
What legitimate cases exist for overloading it?
(Can't say I've ever done that....)
I seem to remember something like a smart pointer class which overrode
operator& because it wanted to return the address of the contained pointer rather than the address of the smart pointer object. Can't remember where I saw it or whether it seemed like a good idea at the time.
Aha, remembered: Microsoft's CComPtr.
Edit: To generalize, it might make sense under the following conditions:
Returning anything other than a legitimate pointer would violate the principle of least astonishment.
It is useful when representing the
& operation in lambda placeholder notation, e.g.
& makes your object behave like a reference (in that respect).
I'm pretty sure that it's a fool's errand to attempt to provide alternatives to built-in references, in particular since references aren't objects at all in C++, and they don't have their own addresses. Instances of your user-defined type inevitably are objects, and do have addresses, even if you disable the normal way of obtaining that address. So it is never a perfect imitation.
But, people are very keen on user-defined alternatives to pointers, so I can sort of see how someone might want to attempt it. I'm not sure they'll avoid creating a type that (mis)behaves in ways that will make its users wish they hadn't bothered.
Four years later, another answer.
Another use I have seen is when you are piggybacking off of the C++ language, but defining your own semantics. Prime example: Boost.Spirit.
Boost.Spirit, in particular Qi for parsing, overloads operators on parsers to provide an EBNF-like syntax for specifying arbitrary parser objects. In particular, the unary
& operator is overloaded to provide the And-Predicate Parser.
And-Predicate Parser (&a)
Syntactic predicates assert a certain conditional syntax to be satisfied before evaluating another production. Similar to semantic predicates, eps, syntactic predicates do not consume any input. The and-predicate, &a, is a positive syntactic predicate that returns a zero length match only if its predicate matches.
Basic look-ahead example: make sure that the last character is a semicolon, but don't consume it, just peek at the next character:
test_phrase_parser("Hello ;", lit("Hello") >> &lit(';'), false);
So in short, the unary
& here has no relation to pointers at all; it has domain-specific semantics which apply to Qi parser objects.
I've done this to good effect in the context of a DSL that generates LLVM code. An example will illustrate. Say
y are values (i.e., objects of type
value). Then the expression
x+y emits an ADD instruction into some code stream. Quite sensibly, the expression
&x emits an instruction to take the address of
Once I used to override operator & (without altering its behavior) as private to the class, in order to protect against occasional creation of smart pointer to the object created in the stack. Still not sure if it was really good idea...
You can overload the address operator to make it private. This could be useful for implementing some sort of baton passing scheme, where the address of the baton cannot be taken. If the baton's constructors are hidden, this can keep the baton's scope airtight.