How can I reliably get an object's address when operator& is overloaded?

A

5

173

Consider the following program:

struct ghost
{
    // ghosts like to pretend that they don't exist
    ghost* operator&() const volatile { return 0; }
};

int main()
{
    ghost clyde;
    ghost* clydes_address = &clyde; // darn; that's not clyde's address :'( 
}

How do I get clyde's address?

I'm looking for a solution that will work equally well for all types of objects. A C++03 solution would be nice, but I'm interested in C++11 solutions too. If possible, let's avoid any implementation-specific behavior.

I am aware of C++11's std::addressof function template, but am not interested in using it here: I'd like to understand how a Standard Library implementor might implement this function template.

Antoine answered 27/6, 2011 at 14:39 Comment(16)

@jalf: That strategy is acceptable, but now that I've punched said individuals in the head, how do I work around their abominable code? :-) – Antoine 27/6, 2011 at 14:54

@jalf Uhm, sometimes you need to overload this operator, and return a proxy object. Though I can’t think of an example just now. – Anaemia 27/6, 2011 at 15:6

@Konrad: me either. If you need that, I'd suggest that a better option might be to rethink your design, because overloading that operator just causes too many problems. :) – Ikeda 27/6, 2011 at 15:20

See also this answer. – Tusk 27/6, 2011 at 18:14

@Konrad: In roughly 20 years of C++ programming I have once attempted to overload that operator. That was at the very beginning of those twenty years. Oh, and I failed to make that usable. Consequently, the operator overloading FAQ entry says "The unary address-of operator should never be overloaded." You'll get a free beer the next time we meet if you can come up with a convincing example for overloading this operator. (I know you're leaving Berlin, so I can safely offer this :)) – Tusk 27/6, 2011 at 18:20

CComPtr<> and CComQIPtr<> have an overloaded operator& – Weber 27/6, 2011 at 23:42

@Simon: but the important question is should they have an overloaded operator&? – Ikeda 28/6, 2011 at 7:0

Well, it allows pointers to them to be passed to functions that expect a pointer to the contained type... But indeed, I'd return a proxy object that is convertible to T ** and CComPtr<T> *. – Weber 28/6, 2011 at 9:0

Don't do it like this. It will trigger an operator char&(). – Antwanantwerp 29/6, 2011 at 20:45

@Simon Richter: I till remember spending a day or so debugging and fixing a problem triggered by this. GAAAH! --- the operator & should use an interface ** OutPtr() / interface ** InOutPtr() instead, that would make it explicit in the call (with acceptable overhead) – Urmia 30/6, 2011 at 12:45

Here're two very similar questions https://mcmap.net/q/56786/-if-an-operator-is-overloaded-for-a-c-class-how-could-i-use-a-default-operator-instead/57428 and https://mcmap.net/q/56097/-most-portable-and-reliable-way-to-get-the-address-of-variable-in-c/57428 – Creatural 6/7, 2011 at 6:47

@curiousguy: Many interesting questions in life tend to be about unpractical things. That said, this question is certainly a practical one for anyone writing a C++ Standard Library implementation. – Antoine 3/12, 2011 at 7:21

@JamesMcNellis "That said, this question is certainly a practical one for anyone writing a C++ Standard Library implementation" for what? – Sutra 3/12, 2011 at 8:5

@curiousguy: std::addressof must be able to obtain the address of an object, even if the object is of a type that overloads arbitrary operators, including conversion operators and the unary &. Further, the Standard Library containers must be instantiable and usable with those perverse types as well (this requirement is new in C++11; it was not present in C++98/03). – Antoine 3/12, 2011 at 8:9

OTOH: "Numeric type requirements" [numeric.requirements] "it does not overload unary operator&." – Sutra 5/12, 2011 at 17:43

@SimonRichter how is CCom*** to be considered something that doesn't need its design rethought??? – Excellence 15/10, 2014 at 13:17

A

102

Update: in C++11, one may use std::addressof instead of boost::addressof.

Let us first copy the code from Boost, minus the compiler work around bits:

template<class T>
struct addr_impl_ref
{
  T & v_;

  inline addr_impl_ref( T & v ): v_( v ) {}
  inline operator T& () const { return v_; }

private:
  addr_impl_ref & operator=(const addr_impl_ref &);
};

template<class T>
struct addressof_impl
{
  static inline T * f( T & v, long ) {
    return reinterpret_cast<T*>(
        &const_cast<char&>(reinterpret_cast<const volatile char &>(v)));
  }

  static inline T * f( T * v, int ) { return v; }
};

template<class T>
T * addressof( T & v ) {
  return addressof_impl<T>::f( addr_impl_ref<T>( v ), 0 );
}

What happens if we pass a reference to function ?

Note: addressof cannot be used with a pointer to function

In C++ if void func(); is declared, then func is a reference to a function taking no argument and returning no result. This reference to a function can be trivially converted into a pointer to function -- from @Konstantin: According to 13.3.3.2 both T & and T * are indistinguishable for functions. The 1st one is an Identity conversion and the 2nd one is Function-to-Pointer conversion both having "Exact Match" rank (13.3.3.1.1 table 9).

The reference to function pass through addr_impl_ref, there is an ambiguity in the overload resolution for the choice of f, which is solved thanks to the dummy argument 0, which is an int first and could be promoted to a long (Integral Conversion).

Thus we simply returns the pointer.

What happens if we pass a type with a conversion operator ?

If the conversion operator yields a T* then we have an ambiguity: for f(T&,long) an Integral Promotion is required for the second argument while for f(T*,int) the conversion operator is called on the first (thanks to @litb)

That's when addr_impl_ref kicks in. The C++ Standard mandates that a conversion sequence may contain at most one user-defined conversion. By wrapping the type in addr_impl_ref and forcing the use of a conversion sequence already, we "disable" any conversion operator that the type comes with.

Thus the f(T&,long) overload is selected (and the Integral Promotion performed).

What happens for any other type ?

Thus the f(T&,long) overload is selected, because there the type does not match the T* parameter.

Note: from the remarks in the file regarding Borland compatibility, arrays do not decay to pointers, but are passed by reference.

What happens in this overload ?

We want to avoid applying operator& to the type, as it may have been overloaded.

The Standard guarantees that reinterpret_cast may be used for this work (see @Matteo Italia's answer: 5.2.10/10).

Boost adds some niceties with const and volatile qualifiers to avoid compiler warnings (and properly use a const_cast to remove them).

Cast T& to char const volatile&
Strip the const and volatile
Apply the & operator to take the address
Cast back to a T*

The const/volatile juggling is a bit of black magic, but it does simplify the work (rather than providing 4 overloads). Note that since T is unqualified, if we pass a ghost const&, then T* is ghost const*, thus the qualifiers have not really been lost.

EDIT: the pointer overload is used for pointer to functions, I amended the above explanation somewhat. I still do not understand why it is necessary though.

The following ideone output sums this up, somewhat.

Aboulia answered 27/6, 2011 at 15:27 Comment(14)

"What happens if we pass a pointer ?" part is incorrect. If we pass a pointer to some type U the addressof function the type 'T' is inferred to be 'U*' and addr_impl_ref will have two overloads: 'f(U*&, long)' and 'f(U**,int)', obviously the first one will be selected. – Schiffman 27/6, 2011 at 16:1

@Konstantin: right, I had thought that the two f overloads where function templates, whereas they are regular member functions of a template class, thanks for pointing it out. (Now I just need to figure out what is the use of the overload, any tip ?) – Aboulia 27/6, 2011 at 16:50

This is a great, well-explained answer. I kind of figured there was a bit more to this than just "cast through char*." Thank you, Matthieu. – Antoine 28/6, 2011 at 13:59

@James: I have had much help from @Konstantin who would strike my head with a stick any time I made a mistake :D – Aboulia 28/6, 2011 at 17:10

@Matthieu: Did I? :D Probably we are just interested in similar questions here, nothing personal. :) – Schiffman 28/6, 2011 at 18:26

Why would it need to work around types that have a conversion function? Would it not prefer the exact match over invoking any conversion function to T*? EDIT: Now I see. It would, but with the 0 argument it would end up in a criss-cross, so would be ambiguous. – Antwanantwerp 29/6, 2011 at 20:28

@James: :D @litb: there are two conversions we wish to avoid. The conversion to T* leads to an ambiguity and the conversion to T& may point to another object. The latter would really bite us, unnoticed (at compile-time). – Aboulia 30/6, 2011 at 6:24

@Matthieu, no the conversion to T& can never happen because the argument is a T already. This is only to avoid the criss-cross. – Antwanantwerp 30/6, 2011 at 14:58

@James https://mcmap.net/q/144763/-why-is-this-ambiguity-here/… – Antwanantwerp 30/6, 2011 at 15:16

"then func is a reference to a function" Hug? There is no reference here! – Sutra 6/12, 2011 at 15:21

In C++11 we can now just use std::addressof – Pipit 5/1, 2015 at 14:0

@paulm: Right! Edited as the first line. – Aboulia 5/1, 2015 at 16:9

it can switch int and long ? static inline T * f( T & v, int) { return reinterpret_cast<T*>( &const_cast<char&>(reinterpret_cast<const volatile char &>(v))); } static inline T * f( T * v, long) { return v; } – Daffodil 13/4, 2016 at 13:35

@zpeng: I am not quite sure, to be honest, since a pointer to reference is invalid and a reference to pointer is valid it seems to me it makes sense to privilege the T* function and thus force a conversion before access to the T&... but maybe I am just paranoid because I cannot think of a counter-example right now. – Aboulia 13/4, 2016 at 13:47

A

106

Use std::addressof.

You can think of it as doing the following behind the scenes:

Reinterpret the object as a reference-to-char
Take the address of that (won’t call the overload)
Cast the pointer back to a pointer of your type.

Existing implementations (including Boost.Addressof) do exactly that, just taking additional care of const and volatile qualification.

Anaemia answered 27/6, 2011 at 14:58 Comment(1)

I like this explanation better than the selected on as it can be readily understood. – Footle 29/6, 2011 at 19:37

A

102