¿Cómo puedo obtener de manera confiable la dirección de un objeto cuando el operador y está sobrecargado?

Considere el siguiente programa:

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 :'( 
}

¿Cómo obtengo clydela dirección?

Estoy buscando una solución que funcione igualmente bien para todo tipo de objetos. Una solución C ++ 03 sería buena, pero también estoy interesado en las soluciones C ++ 11. Si es posible, evitemos cualquier comportamiento específico de implementación.

Soy consciente de la std::addressofplantilla de función de C ++ 11 , pero no estoy interesado en usarla aquí: me gustaría entender cómo un implementador de la Biblioteca estándar podría implementar esta plantilla de función.

Actualización: en C ++ 11, uno puede usar en std::addressoflugar de boost::addressof.

Copiemos primero el código de Boost, menos el trabajo del compilador alrededor de 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 );
}

¿Qué sucede si pasamos una referencia a la función ?

Nota: addressofno se puede usar con un puntero para funcionar

En C ++ si void func();se declara, entonces funces una referencia a una función que no toma argumentos y no devuelve ningún resultado. Esta referencia a una función se puede convertir trivialmente en un puntero a la función, desde @Konstantin: De acuerdo con 13.3.3.2 a ambos, T &y no se T *pueden distinguir para las funciones. La primera es una conversión de identidad y la segunda es la conversión de función a puntero, ambas con rango de "coincidencia exacta" (13.3.3.1.1 tabla 9).

La referencia a la función pasa addr_impl_ref, hay una ambigüedad en la resolución de sobrecarga para la elección de f, que se resuelve gracias al argumento ficticio 0, que es el intprimero y podría promoverse a a long(Conversión integral).

Por lo tanto, simplemente devolvemos el puntero.

¿Qué sucede si pasamos un tipo con un operador de conversión?

Si el operador de conversión produce un a, T*entonces tenemos una ambigüedad: f(T&,long)se requiere una promoción integral para el segundo argumento, mientras que para f(T*,int)el operador de conversión se llama al primero (gracias a @litb)

Ahí es cuando addr_impl_refentra en acción. El estándar C ++ exige que una secuencia de conversión pueda contener como máximo una conversión definida por el usuario. Al envolver el tipo addr_impl_refy forzar el uso de una secuencia de conversión, "deshabilitamos" cualquier operador de conversión con el que viene el tipo.

Así f(T&,long)se selecciona la sobrecarga (y se realiza la Promoción Integral).

¿Qué pasa con cualquier otro tipo?

Por lo tanto, f(T&,long)se selecciona la sobrecarga, porque allí el tipo no coincide con el T*parámetro.

Nota: a partir de las observaciones en el archivo con respecto a la compatibilidad de Borland, las matrices no se descomponen en punteros, sino que se pasan por referencia.

¿Qué pasa en esta sobrecarga?

Queremos evitar aplicar operator&al tipo, ya que puede haber sido sobrecargado.

La Norma garantiza que reinterpret_castse puede utilizar para este trabajo (consulte la respuesta de @Matteo Italia: 5.2.10 / 10).

Boost agrega algunas sutilezas consty volatilecalificadores para evitar advertencias del compilador (y usa adecuadamente a const_castpara eliminarlos).

• Fundido T&achar const volatile&
• Pelar el constyvolatile
• Solicite al &operador que tome la dirección
• Echado de vuelta a un T*

El const/ volatilemalabarismo es un poco de magia negra, pero simplifica el trabajo (en lugar de proporcionar 4 sobrecargas). Tenga en cuenta que, dado que Tno está calificado, si pasamos un ghost const&, entonces lo T*es ghost const*, por lo tanto, los calificadores no se han perdido realmente.

EDITAR: la sobrecarga del puntero se utiliza para el puntero a las funciones, modifiqué un poco la explicación anterior. Sin embargo, todavía no entiendo por qué es necesario .

La siguiente salida de ideone resume esto, de alguna manera.

Uso std::addressof.

Puedes pensar que hace lo siguiente detrás de escena:

1. Reinterpretar el objeto como una referencia a char
2. Tome la dirección de eso (no llamará a la sobrecarga)
3. Lanza el puntero a un puntero de tu tipo.

Las implementaciones existentes (incluyendo Boost.Addressof) hacen exactamente eso, solo teniendo cuidado adicional consty volatilecalificación.

El truco detrás boost::addressofy la implementación proporcionada por @Luc Danton se basa en la magia de reinterpret_cast; la norma establece explícitamente en §5.2.10 ¶10 que

Una expresión de tipo lvalue T1se puede convertir al tipo "referencia a T2" si una expresión de tipo "puntero a T1" se puede convertir explícitamente al tipo "puntero a T2" utilizando a reinterpret_cast. Es decir, un reparto de referencia reinterpret_cast<T&>(x)tiene el mismo efecto que la conversión *reinterpret_cast<T*>(&x)con los operadores integrados &y *. El resultado es un valor de l que se refiere al mismo objeto que el valor de origen, pero con un tipo diferente.

Ahora, esto nos permite convertir una referencia de objeto arbitraria a a char &(con una calificación de cv si la referencia está calificada por cv), porque cualquier puntero se puede convertir a a (posiblemente calificado por cv) char *. Ahora que tenemos un char &, la sobrecarga del operador en el objeto ya no es relevante, y podemos obtener la dirección con el &operador incorporado .

La implementación de impulso agrega algunos pasos para trabajar con objetos calificados para cv: el primero reinterpret_castse realiza para const volatile char &, de lo contrario, un char &molde simple no funcionaría consty / o volatilereferencias ( reinterpret_castno se puede eliminar const). Luego, consty volatilese elimina con const_cast, se toma la dirección &y se realiza una final reinterpet_castpara el tipo "correcto".

Se const_castnecesita para eliminar el const/ volatileque podría haberse agregado a referencias no constantes / volátiles, pero no "daña" lo que fue un const/ volatilereferencia en primer lugar, porque el final reinterpret_castvolverá a agregar la calificación cv si era allí en primer lugar ( reinterpret_castno puede eliminar el constpero puede agregarlo).

En cuanto al resto del código addressof.hpp, parece que la mayor parte es para soluciones alternativas. El static inline T * f( T * v, int )parece ser necesario sólo para el compilador Borland, pero su presencia introduce la necesidad de que addr_impl_ref, de lo contrario los tipos de puntero serían capturados por esta segunda sobrecarga.

Editar : las diversas sobrecargas tienen una función diferente, vea @Matthieu M. excelente respuesta .

Bueno, ya no estoy seguro de esto tampoco; Debería investigar más ese código, pero ahora estoy cocinando la cena :), lo echaré un vistazo más tarde.

He visto una implementación de addressofhacer esto:

char* start = &reinterpret_cast<char&>(clyde);
ghost* pointer_to_clyde = reinterpret_cast<ghost*>(start);

¡No me preguntes cómo se conforma esto!

Eche un vistazo a boost :: addressof y su implementación.