Does it ever make sense to overload unary operator &?

So, C++ allows overloading the unary operator &(address). Are you aware of any real-world example when operator & was rightfully overloaded? And a second, more specific question, are you aware of any real-world example when operator & was rightfully overloaded while preserving address semantics? 开发者_如何学编程TIA

---

I've got 207 real-world examples of operator &(): Code search 1, Code search 2.

Including SafeInt<> (to get the underlying naked integer), boost::gil (apparently also to yield the raw data), Mozilla (that say "it is risky to define operator&, but, hey, we know what we're doing."), wxWidgets, Armagetron and lots of more.

It seems some use the iterator idiom &*it to get a raw reference or pointer backwards, and write *&it to get a raw reference and &it to get a raw pointer.

Notice that once your type overloads operator& and returns something different than the built-in operator, your type is not CopyConstructible anymore (in C++03 - C++0x seems to have lifted it), and so cannot be used as element-type in a Standard container anymore.

---

It appears to be used in ATL, e.g http://msdn.microsoft.com/en-us/library/5s6et3yb.aspx

---

I don't know of a concrete example off-hand, but I could imagine a container class where you might want to return a smart pointer or an iterator. I'm not saying this necessarily makes sense, though.

---

One good reason to overload it might be to make it private, to prevent users from using it. I can't this think of any real-world example where you would want to prevent this, but it seems to be the most logical reason to overload it.

---

I did it once when an object had a special-purpose smart pointer. operator& quietly 'lifted' a stack-allocated object into a heap-based smart pointer version, and this operator behaved differently once the object was inside the pointer.

I don't have the code any more, but there was a reason for it at the time. It's certainly not a decision to take lightly, this road is lined with corpses.

---

I overloaded this operator when writing classes for interacting with Direct3D. It was a smart pointer class that needed to have T** returned from operator& so that it could be used in functions that expect pointer-to-pointer. T** semantics are rare but you do need them in some situations.