Come posso ottenere in modo affidabile l'indirizzo di un oggetto quando l'operatore è sovraccarico?

Considera il seguente programma:

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

Come ottengo clydel'indirizzo?

Sto cercando una soluzione che funzioni ugualmente bene per tutti i tipi di oggetti. Una soluzione C ++ 03 sarebbe bella, ma sono interessato anche alle soluzioni C ++ 11. Se possibile, evitiamo qualsiasi comportamento specifico dell'implementazione.

Sono a conoscenza del std::addressofmodello di funzione di C ++ 11 , ma non mi interessa utilizzarlo qui: vorrei capire come un implementatore della libreria standard potrebbe implementare questo modello di funzione.

Aggiornamento: in C ++ 11, si può usare al std::addressofposto di boost::addressof.

Copiamo prima il codice da Boost, meno che il compilatore funzioni attorno ai bit:

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 );
}

Cosa succede se passiamo un riferimento alla funzione ?

Nota: addressofnon può essere utilizzato con un puntatore per funzionare

In C ++ se void func();è dichiarato, allora funcè un riferimento a una funzione che non accetta alcun argomento e non restituisce alcun risultato. Questo riferimento a una funzione può essere banalmente convertito in un puntatore a funzione - da @Konstantin: secondo 13.3.3.2 entrambi T &e T *sono indistinguibili per le funzioni. Il primo è una conversione di identità e il secondo è una conversione da funzione a puntatore entrambi con rango "Corrispondenza esatta" (13.3.3.1.1 tabella 9).

Il riferimento alla funzione passa attraverso addr_impl_ref, c'è un'ambiguità nella risoluzione del sovraccarico per la scelta di f, che è risolta grazie all'argomento fittizio 0, che è il intprimo e potrebbe essere promosso a long(Conversione integrale).

Quindi restituiamo semplicemente il puntatore.

Cosa succede se passiamo un tipo con un operatore di conversione?

Se l'operatore di conversione produce a T*allora abbiamo un'ambiguità: per f(T&,long)una promozione integrale è necessaria per il secondo argomento mentre per f(T*,int)l'operatore di conversione viene chiamato il primo (grazie a @litb)

Ecco quando addr_impl_refentra in gioco. Lo standard C ++ impone che una sequenza di conversione possa contenere al massimo una conversione definita dall'utente. Inserendo il tipo addr_impl_refe forzando già l'uso di una sequenza di conversione, "disabilitiamo" qualsiasi operatore di conversione fornito dal tipo.

In tal modo f(T&,long)viene selezionato il sovraccarico (e viene eseguita la promozione integrale).

Cosa succede per qualsiasi altro tipo?

Quindi f(T&,long)viene selezionato il sovraccarico, perché lì il tipo non corrisponde al T*parametro.

Nota: dalle osservazioni nel file relative alla compatibilità di Borland, le matrici non si deteriorano in puntatori, ma vengono passate per riferimento.

Cosa succede in questo sovraccarico?

Vogliamo evitare di applicare operator&al tipo, poiché potrebbe essere stato sovraccarico.

Lo standard garantisce che reinterpret_castpuò essere utilizzato per questo lavoro (vedi la risposta di @Matteo Italia: 5.2.10 / 10).

Boost aggiunge alcuni aspetti positivi conste volatilequalificatori per evitare gli avvisi del compilatore (e utilizzare correttamente a const_castper rimuoverli).

• Cast T&tochar const volatile&
• Striscia constevolatile
• Applicare l' &operatore per prendere l'indirizzo
• Torna a a T*

Il const/ volatilegiocoleria è un po 'di magia nera, ma semplifica il lavoro (piuttosto che fornire 4 sovraccarichi). Si noti che poiché Tnon è qualificato, se si passa a ghost const&, allora lo T*è ghost const*, quindi le qualificazioni non sono state realmente perse.

EDIT: il sovraccarico del puntatore viene utilizzato per il puntatore alle funzioni, ho modificato in qualche modo la spiegazione sopra. Non capisco ancora perché sia necessario .

Il seguente output di ideone lo riassume in qualche modo.

Usa std::addressof.

Puoi pensarlo nel modo seguente dietro le quinte:

1. Reinterpreta l'oggetto come riferimento a carattere
2. Prendi l'indirizzo di quello (non chiamerà il sovraccarico)
3. Trasmetti il ​​puntatore a un puntatore del tuo tipo.

Le implementazioni esistenti (incluso Boost.Addressof) fanno esattamente questo, solo prendendosi cura conste volatilequalificazione aggiuntive .

Il trucco boost::addressofe l'implementazione forniti da @Luc Danton si basano sulla magia di reinterpret_cast; lo standard afferma esplicitamente in §5.2.10 ¶10 che

È T1possibile eseguire il cast di un'espressione di tipo lvalue nel tipo “riferimento a T2” se un'espressione di tipo “puntatore a T1” può essere esplicitamente convertita nel tipo “puntatore a T2” utilizzando a reinterpret_cast. Cioè, un cast di riferimento reinterpret_cast<T&>(x)ha lo stesso effetto della conversione *reinterpret_cast<T*>(&x)con l' operatore incorporato &e gli *operatori. Il risultato è un valore che fa riferimento allo stesso oggetto del valore di origine, ma con un tipo diverso.

Ora, questo ci consente di convertire un riferimento ad un oggetto arbitrario in un char &(con una qualifica cv se il riferimento è qualificato in cv), perché qualsiasi puntatore può essere convertito in un (possibilmente qualificato in cv) char *. Ora che abbiamo un char &, il sovraccarico dell'operatore sull'oggetto non è più rilevante e possiamo ottenere l'indirizzo con l' &operatore incorporato .

L'implementazione del boost aggiunge alcuni passaggi per lavorare con oggetti qualificati per cv: il primo reinterpret_castviene fatto const volatile char &, altrimenti un char &cast normale non funzionerebbe per conste / o volatileriferimenti ( reinterpret_castnon può essere rimosso const). Quindi conste volatileviene rimosso con const_cast, l'indirizzo viene preso con &e viene eseguito un tipo finale reinterpet_cast"corretto".

Il const_castè necessario per rimuovere il const/ volatileche avrebbe potuto essere aggiunto al non-const / riferimenti volatili, ma non "danno": quello che era un const/ volatiledi riferimento in primo luogo, perché la finale reinterpret_castsi ri-aggiungere il cv-qualificazione se fosse lì in primo luogo ( reinterpret_castnon è possibile rimuovere il constma può aggiungerlo).

Per quanto riguarda il resto del codice addressof.hpp, sembra che la maggior parte sia per soluzioni alternative. L' static inline T * f( T * v, int )sembra essere necessario solo per il compilatore Borland, ma la sua presenza introduce la necessità di addr_impl_ref, altrimenti tipi di puntatore sarebbe stato catturato da questa seconda sovraccarico.

Modifica : i vari sovraccarichi hanno una funzione diversa, vedi @Matthieu M. risposta eccellente .

Bene, non ne sono più sicuro neanche; Dovrei indagare ulteriormente su quel codice, ma ora sto cucinando la cena :), ci darò un'occhiata più tardi.

Ho visto un'implementazione di addressoffare questo:

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

Non chiedermi quanto sia conforme!

Dai un'occhiata a boost :: addressof e alla sua implementazione.