If you're asking about all languages then I don't think it's reasonable to talk about "the & operator". The token &
could have all sorts of meanings in different languages, operator and otherwise.
For example in C alone there are two distinct &
operators (unary address-of and binary bitwise-and). Unary &
in C and related languages is the only example I can immediately think of, of a use I've encountered that meets your criteria.
However, C++ adds operator overloading so that they can mean anything you like for user-defined classes, and in addition the &
character has meaning in type declarations. In C++0x the &&
token has meaning in type declarations too.
A language along the lines of APL or J could "reasonably" use an &
operator to mean pretty much anything, since there is no expectation that code in those languages bears any resemblance at all to C-like languages. Not sure if either of those two does in fact use either &
or &&
.
What meanings it's "reasonable" for a binary &
operator overload to have in C++ is a matter of taste - normally it would be something that's analogous to bitwise &
in some way, because the values represented by your class can be considered as a sequence of bits in some way. Doesn't have to be, though, as long as it's something that makes sense in the domain. Normally it's fairly "unreasonable" to use an &
overload just because &
happens to be unused. But if your class represents something fairly abstruse in mathematics and you need a third binary operator after +
and *
, I suppose you'd start looking around. If what you want is something with even lower precedence than +
, binary &
is a candidate. I can't for the moment think of any structures in abstract algebra that want such a thing, but that doesn't mean there aren't any.
Overloading operator&&
in C++ is moderately antisocial, since the un-overloaded version of the operator short-circuits and overloaded versions don't. C++ programmers are used to writing expressions like if (p && *p != 0)
, so by overloading operator&&
you're in effect messing with a control structure.
Overloading unary operator&
in C++ is extremely antisocial. It stops people taking pointers to your objects. IIRC there are some awkward cases where common implementations of standard templates require of their template parameters that unary operator&
results in a pointer (or at least a very pointer-like thing). This is not documented in the requirements for the argument, but is either almost or completely unavoidable when the library-writer comes to implement the template. So the overload would place restrictions on the use of the class that can't be deduced from the standard, and there'd better be a very good reason for that.
[Edit: what I didn't know when I wrote this, but do know now, is that template-writers could work around the need to use unary operator&
with template parameters where the standard doesn't specify what &
does for that type (i.e. all of them). You can do what boost::addressof
does, which is:
reinterpret_cast<Foo*>(&reinterpret_cast<char&>(foo))
The standard doesn't require much of reinterpet_cast
, but since we're talking about standard templates they know exactly what it does in the implementation, and anyway it's legal to reinterpret an object as chars. I think this is guaranteed to work - but if not the implementation can ensure that it does work if necessary to write fully conforming standard templates.
But, if your implementation doesn't go to these lengths to avoid calling an overloaded operator&
, the original problem remains.]