Wie kann ich die Adresse eines Objekts zuverlässig abrufen, wenn der Operator & überlastet ist?

Betrachten Sie das folgende Programm:

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

Wie bekomme ich die clydeAdresse?

Ich suche nach einer Lösung, die für alle Arten von Objekten gleich gut funktioniert. Eine C ++ 03-Lösung wäre schön, aber ich interessiere mich auch für C ++ 11-Lösungen. Vermeiden Sie nach Möglichkeit implementierungsspezifisches Verhalten.

Ich kenne die std::addressofFunktionsvorlage von C ++ 11 , bin aber nicht daran interessiert, sie hier zu verwenden: Ich möchte verstehen, wie ein Standard Library-Implementierer diese Funktionsvorlage implementieren kann.

Update: In C ++ 11 kann man std::addressofanstelle von verwenden boost::addressof.

Kopieren wir zuerst den Code von Boost, abzüglich der Compiler-Umgehung von 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 );
}

Was passiert, wenn wir einen Verweis auf die Funktion übergeben ?

Hinweis: addressofKann nicht mit einem Zeiger auf die Funktion verwendet werden

Wenn in C ++ void func();deklariert ist, funcist dies ein Verweis auf eine Funktion, die kein Argument akzeptiert und kein Ergebnis zurückgibt. Dieser Verweis auf eine Funktion kann trivial in einen Zeiger auf eine Funktion umgewandelt werden - von @Konstantin: Nach 13.3.3.2 sind beide T &und T *für Funktionen nicht zu unterscheiden. Die erste ist eine Identitätskonvertierung und die zweite ist eine Funktion-zu-Zeiger-Konvertierung, die beide den Rang "Exakte Übereinstimmung" haben (13.3.3.1.1, Tabelle 9).

Der Verweis auf die Funktion geht durch addr_impl_ref, es gibt eine Mehrdeutigkeit in der Überlastungsauflösung für die Auswahl von f, die dank des Dummy-Arguments gelöst wird, das eine Premiere 0ist intund zu einer long(Integral Conversion) befördert werden könnte.

Wir geben also einfach den Zeiger zurück.

Was passiert, wenn wir einen Typ mit einem Konvertierungsoperator übergeben?

Wenn der Konvertierungsoperator a ergibt T*, haben wir eine Mehrdeutigkeit: Für f(T&,long)das zweite Argument ist eine integrale Promotion erforderlich, während für f(T*,int)den Konvertierungsoperator das erste aufgerufen wird (danke an @litb).

Das ist , wenn addr_impl_refTritten an. Die C ++ Standard - Aufträge , daß eine Konvertierungssequenz höchstens einen benutzerdefinierten Umwandlung enthalten. Indem addr_impl_refwir den Typ einschließen und die Verwendung einer Konvertierungssequenz bereits erzwingen, "deaktivieren" wir jeden Konvertierungsoperator, mit dem der Typ geliefert wird.

Somit wird die f(T&,long)Überlastung ausgewählt (und die integrale Förderung durchgeführt).

Was passiert bei einem anderen Typ?

Somit wird die f(T&,long)Überladung ausgewählt, da dort der Typ nicht mit dem T*Parameter übereinstimmt .

Hinweis: Aus den Anmerkungen in der Datei zur Borland-Kompatibilität geht hervor, dass Arrays nicht in Zeiger zerfallen, sondern als Referenz übergeben werden.

Was passiert bei dieser Überlastung?

Wir möchten vermeiden operator&, dass der Typ angewendet wird, da er möglicherweise überladen ist.

Der Standard garantiert, dass reinterpret_castfür diese Arbeit verwendet werden kann (siehe Antwort von @Matteo Italia: 5.2.10 / 10).

Boost fügt einige Feinheiten mit constund volatileQualifikationsmerkmalen hinzu, um Compiler-Warnungen zu vermeiden (und verwendet a ordnungsgemäß const_cast, um sie zu entfernen).

• Besetzung T&zuchar const volatile&
• Zieh das constund ausvolatile
• Wenden Sie den &Operator an, um die Adresse zu übernehmen
• Wirf zurück zu a T*

Das const/ volatileJonglieren ist ein bisschen schwarze Magie, aber es vereinfacht die Arbeit (anstatt 4 Überladungen bereitzustellen). Beachten Sie, dass, da Tunqualifiziert ist, wenn wir a bestehen ghost const&, dies der Fall T*ist ghost const*, die Qualifikanten nicht wirklich verloren gegangen sind.

BEARBEITEN: Die Zeigerüberladung wird für den Zeiger auf Funktionen verwendet, ich habe die obige Erklärung etwas geändert. Ich verstehe immer noch nicht, warum es notwendig ist .

Die folgende Ideone-Ausgabe fasst dies etwas zusammen.

Verwenden Sie std::addressof.

Sie können sich vorstellen, hinter den Kulissen Folgendes zu tun:

1. Interpretieren Sie das Objekt als Referenz auf Zeichen neu
2. Nehmen Sie die Adresse davon (wird die Überladung nicht anrufen)
3. Wirf den Zeiger zurück auf einen Zeiger deines Typs.

Bestehende Implementierungen (einschließlich Boost.Addressof) tun genau das, indem sie sich nur um zusätzliche Pflege constund volatileQualifizierung kümmern .

Der Trick dahinter boost::addressofund die Implementierung von @Luc Danton beruhen auf der Magie des reinterpret_cast; Der Standard besagt ausdrücklich in §5.2.10 ¶10, dass

Ein lvalue-Ausdruck vom Typ T1kann in den Typ "Verweis auf T2" umgewandelt werden, wenn ein Ausdruck vom Typ "Zeiger auf T1" mit a explizit in den Typ "Zeiger auf T2" konvertiert werden kann reinterpret_cast. Das heißt, eine Referenzbesetzung reinterpret_cast<T&>(x)hat den gleichen Effekt wie die Konvertierung *reinterpret_cast<T*>(&x)mit den integrierten Operatoren &und *Operatoren. Das Ergebnis ist ein l-Wert, der sich auf dasselbe Objekt wie der Quell-l-Wert bezieht, jedoch einen anderen Typ hat.

Dies ermöglicht es uns nun, eine beliebige Objektreferenz in a zu konvertieren char &(mit einer Lebenslaufqualifikation, wenn die Referenz cv-qualifiziert ist), da jeder Zeiger in a konvertiert werden kann (möglicherweise cv-qualifiziert) char *. Nachdem wir eine haben char &, ist die Überladung des Operators für das Objekt nicht mehr relevant, und wir können die Adresse mit dem eingebauten &Operator abrufen .

Die Boost-Implementierung fügt einige Schritte hinzu, um mit cv-qualifizierten Objekten zu arbeiten: Der erste Schritt reinterpret_castwird ausgeführt const volatile char &, andernfalls würde eine einfache char &Besetzung für constund / oder volatileReferenzen nicht funktionieren ( reinterpret_castkann nicht entfernt werden const). Dann wird das constund volatilemit entfernt const_cast, die Adresse mit genommen &und ein endgültiger reinterpet_castbis "korrekter" Typ erstellt.

Das const_castwird benötigt, um das const/ zu entfernen, das volatilenicht konstanten / flüchtigen Referenzen hinzugefügt werden könnte, aber es "schadet" nicht, was eine const/ volatileReferenz an erster Stelle war, da das Finale reinterpret_castdie Lebenslaufqualifikation erneut hinzufügt, wenn dies der Fall ist dort an erster Stelle ( reinterpret_castkann das nicht entfernen const, kann es aber hinzufügen).

Was den Rest des Codes betrifft addressof.hpp, so scheint es, dass das meiste davon für Problemumgehungen ist. Das static inline T * f( T * v, int )scheint nur für den Borland-Compiler erforderlich zu sein, aber sein Vorhandensein macht es erforderlich addr_impl_ref, da sonst Zeigertypen von dieser zweiten Überladung erfasst würden.

Bearbeiten : Die verschiedenen Überladungen haben unterschiedliche Funktionen, siehe @Matthieu M. ausgezeichnete Antwort .

Nun, da bin ich mir auch nicht mehr sicher. Ich sollte diesen Code weiter untersuchen, aber jetzt koche ich das Abendessen :), ich werde es mir später ansehen.

Ich habe eine Implementierung von addressofdo this gesehen:

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

Fragen Sie mich nicht, wie konform das ist!

Schauen Sie sich boost :: addressof an und seine Implementierung an.