Jak niezawodnie uzyskać adres obiektu, gdy operator & jest przeciążony?

Rozważ następujący 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 :'( 
}

Jak uzyskać clydeadres?

Szukam rozwiązania, które sprawdzi się równie dobrze na wszystkich typach obiektów. Rozwiązanie C ++ 03 byłoby fajne, ale interesują mnie też rozwiązania C ++ 11. Jeśli to możliwe, unikajmy wszelkich zachowań specyficznych dla implementacji.

Znam std::addressofszablon funkcji C ++ 11 , ale nie jestem zainteresowany użyciem go tutaj: chciałbym zrozumieć, w jaki sposób osoba wdrażająca bibliotekę standardową może zaimplementować ten szablon funkcji.

Aktualizacja: w C ++ 11 std::addressofzamiast boost::addressof.

Najpierw skopiujmy kod z Boost, bez kompilatora obejść bity:

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

Co się stanie, jeśli przekażemy odniesienie do funkcji ?

Uwaga: addressofnie można używać ze wskaźnikiem do funkcji

W C ++ if void func();jest zadeklarowane, to funcjest odwołaniem do funkcji nie pobierającej argumentu i nie zwracającej wyniku. To odniesienie do funkcji można w trywialny sposób przekształcić we wskaźnik do funkcji - z @Konstantin: Zgodnie z 13.3.3.2 zarówno T &i T *są nierozróżnialne dla funkcji. Pierwsza z nich to konwersja tożsamości, a druga to konwersja funkcji do wskaźnika, obie mają rangę „Dokładne dopasowanie” (13.3.3.1.1 tabela 9).

Odniesienie do funkcji przejść addr_impl_refnie jest niejednoznaczność rozdzielczości przeciążeniem wyboru f, który jest rozwiązany dzięki argumentu zastępczą 0, która jest intpierwszym i może być podniesione na long(całka konwersji).

W ten sposób po prostu zwracamy wskaźnik.

Co się stanie, jeśli przekażemy typ z operatorem konwersji?

Jeśli operator konwersji daje a, T*to mamy niejednoznaczność: ponieważ f(T&,long)Integral Promotion jest wymagana dla drugiego argumentu, a dla f(T*,int)konwersji operator jest wywoływany na pierwszym (dzięki @litb)

Wtedy addr_impl_refzaczyna się. Standard C ++ nakazuje, aby sekwencja konwersji zawierała co najwyżej jedną konwersję zdefiniowaną przez użytkownika. Zawijając typ addr_impl_refi wymuszając już użycie sekwencji konwersji, „wyłączamy” każdy operator konwersji, z którym ten typ pochodzi.

W ten sposób f(T&,long)wybierane jest przeciążenie (i wykonywana jest promocja integralna).

Co dzieje się z każdym innym typem?

W ten sposób f(T&,long)wybrane jest przeciążenie, ponieważ tam typ nie pasuje do T*parametru.

Uwaga: z uwag w pliku dotyczących kompatybilności Borlanda, tablice nie rozpadają się na wskaźniki, ale są przekazywane przez odniesienie.

Co się dzieje w tym przeciążeniu?

Chcemy uniknąć stosowania operator&do typu, ponieważ mógł być przeciążony.

Standardowe gwarancje, które reinterpret_castmożna wykorzystać w tej pracy (patrz odpowiedź @Matteo Italia: 5.2.10 / 10).

Boost dodaje kilka dodatków z kwalifikatorami consti, volatileaby uniknąć ostrzeżeń kompilatora (i poprawnie użyj a, const_castaby je usunąć).

• Przesyłaj T&dochar const volatile&
• Usuń constivolatile
• Zastosuj &operatora, aby przejąć adres
• Odrzuć z powrotem do T*

const/ volatileŻonglerka jest nieco czarnej magii, ale ma uprościć pracę (raczej niż dostarczanie 4 przeciążeń). Zauważ, że ponieważ Tjest niekwalifikowany, jeśli zdamy a ghost const&, to T*jest ghost const*, więc kwalifikatory tak naprawdę nie zostały utracone.

EDYCJA: przeciążenie wskaźnika służy do wskazywania wskaźników do funkcji, nieco poprawiłem powyższe wyjaśnienie. Nadal nie rozumiem, dlaczego jest to konieczne .

Poniższe wyniki ideone nieco to podsumowują.

Użyj std::addressof.

Możesz myśleć o tym jako o wykonywaniu następujących czynności za kulisami:

1. Zinterpretuj ponownie obiekt jako odniesienie do znaku
2. Weź adres tego (nie wywoła przeciążenia)
3. Przerzuć wskaźnik z powrotem na wskaźnik swojego typu.

Istniejące implementacje (w tym Boost.Addressof) zrobić dokładnie to, po prostu biorąc dodatkową opiekę consti volatilekwalifikacji.

Sztuczka stojąca za boost::addressofi implementacja dostarczona przez @Luc Danton opiera się na magii reinterpret_cast; standard wyraźnie stwierdza w §5.2.10, ak.10

Wyrażenie l-wartości typu T1można rzutować na typ „odwołanie do T2”, jeśli wyrażenie typu „wskaźnik do T1” można jawnie przekonwertować na typ „wskaźnik do T2” przy użyciu rozszerzenia reinterpret_cast. Oznacza to, że rzutowanie referencyjne reinterpret_cast<T&>(x)ma taki sam efekt, jak konwersja *reinterpret_cast<T*>(&x)przy użyciu operatorów wbudowanych &i *. Wynikiem jest lwartość, która odnosi się do tego samego obiektu co źródłowa lwartość, ale z innym typem.

Teraz pozwala nam to przekonwertować dowolne odwołanie do obiektu na a char &(z kwalifikacją cv, jeśli referencja jest kwalifikowana jako cv), ponieważ dowolny wskaźnik można przekonwertować na (prawdopodobnie kwalifikowany cv) char *. Teraz, gdy mamy a char &, przeciążenie operatora na obiekcie nie jest już istotne i możemy uzyskać adres za pomocą &operatora wbudowanego .

Implementacja przyspieszenia dodaje kilka kroków do pracy z obiektami kwalifikowanymi w cv: pierwszy reinterpret_castjest wykonywany const volatile char &, w przeciwnym razie zwykłe char &rzutowanie nie działałoby dla consti / lub volatilereferencji ( reinterpret_castnie można ich usunąć const). Następnie usuwane jest consti za volatilepomocą const_cast, adres jest brany za pomocą &, a końcowe reinterpet_castdo „prawidłowego” typu jest wykonywane.

const_castJest potrzebne do usunięcia const/ volatile, które mogły zostać dodane do const / Referencje lotnych, ale nie „szkodzić”, co to jest const/ volatileodniesienia w pierwszej kolejności, ponieważ ostateczna reinterpret_castponownie dodać CV kwalifikacje, czy to tam na pierwszym miejscu ( reinterpret_castnie można usunąć, constale można go dodać).

Co do reszty kodu w programie addressof.hpp, wydaje się, że większość z niego dotyczy obejść. static inline T * f( T * v, int )Wydaje się być potrzebna tylko dla kompilatora Borland, ale jego obecność wprowadza konieczność addr_impl_ref, inaczej typy wskaźnik byłby złapany przez tego drugiego przeciążenia.

Edycja : różne przeciążenia mają inną funkcję, patrz @Matthieu M. doskonała odpowiedź .

Cóż, tego też nie jestem już pewien; Powinienem dokładniej zbadać ten kod, ale teraz gotuję obiad :), przyjrzę się temu później.

Widziałem implementację addressofzrób to:

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

Nie pytajcie mnie, jak to jest zgodne!

Przyjrzyj się boost :: addressof i jego implementacji.