Як я можу надійно отримати адресу об’єкта, коли оператор & перевантажений?

Розглянемо наступну програму:

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

Як мені отримати clydeадресу?

Я шукаю рішення, яке буде однаково добре працювати для всіх типів об’єктів. Рішення C ++ 03 було б непогано, але мене цікавлять і рішення C ++ 11. Якщо можливо, давайте уникати будь-якої поведінки, що залежить від впровадження.

Мені відомо про std::addressofшаблон функції C ++ 11 , але мені тут не цікаво: я хотів би зрозуміти, як реалізатор стандартної бібліотеки може реалізувати цей шаблон функції.

Оновлення: на C ++ 11 можна використовувати std::addressofзамість boost::addressof.

Спершу скопіюємо код з Boost, за вирахуванням роботи компілятора навколо бітів:

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

Що станеться, якщо ми передамо посилання на функцію ?

Примітка: addressofне можна використовувати вказівник для функціонування

У C ++ якщо void func();оголошено, то funcце посилання на функцію, яка не має аргументів і не повертає результату. Це посилання на функцію можна тривіально перетворити на вказівник на функцію - з @Konstantin: Згідно з п. 13.3.3.2 і те, T &і інше T *не відрізняється від функцій. Перший - це перетворення ідентичності, а другий - перетворення функції вказівник, обидва мають ранг "Точна відповідність" (таблиця 13.3.3.1.1).

Посилання на функцію проходить через addr_impl_ref, існує невизначеність у вирішенні перевантаження для вибору f, яка вирішується завдяки фіктивному аргументу 0, який є intпершим і може бути підвищений до long(інтегрального перетворення).

Таким чином, ми просто повертаємо вказівник.

Що станеться, якщо ми передамо тип оператору перетворення?

Якщо оператор конверсії дає a, T*ми маємо неоднозначність: для f(T&,long)інтегрального просування потрібно другий аргумент, тоді як для f(T*,int)оператора конверсії викликається перший (завдяки @litb)

Це коли addr_impl_refпочинається. Стандарт C ++ передбачає, що послідовність перетворень може містити щонайменше одне визначене користувачем перетворення. Увімкнувши тип addr_impl_refі змусивши вже використовувати послідовність перетворень, ми "відключаємо" будь-якого оператора перетворення, до якого входить цей тип.

Таким чином f(T&,long)вибирається перевантаження (і виконується інтегральне просування).

Що відбувається з будь-яким іншим типом?

Таким чином f(T&,long), вибирається перевантаження, оскільки там тип не відповідає T*параметру.

Примітка: із зауважень у файлі щодо сумісності Borland масиви не відпадають у покажчики, а передаються посиланням.

Що відбувається при цій перевантаженні?

Ми хочемо уникати застосування operator&до типу, оскільки він, можливо, перевантажений.

Стандартні гарантії, які reinterpret_castможуть бути використані для цієї роботи (див. Відповідь @Matteo Italia: 5.2.10 / 10).

Boost додає деякі приналежності constта volatileкласифікатори, щоб уникнути попереджень компілятора (і належним чином використовувати const_castдля їх видалення).

• Cast T&доchar const volatile&
• Смугайте constіvolatile
• Застосуйте &оператора, щоб взяти адресу
• Повернення до а T*

const/ volatileЖонглювання трохи чорної магія, але це спростить роботу (а не надання 4 перевантажень). Зауважимо, що оскільки Tце некваліфіковане, якщо ми проходимо а ghost const&, то T*є ghost const*, таким чином кваліфікатори насправді не програли.

EDIT: перевантаження вказівника використовується для вказівника на функції, я дещо змінив вищевказане пояснення. Я досі не розумію, навіщо це потрібно .

Наступний вихід ідеону дещо підсумовує це.

Використовуйте std::addressof.

Ви можете подумати, що це робиться за кулісами:

1. Повторно інтерпретуйте об'єкт як посилання на графік
2. Візьміть адресу, яка не буде викликати перевантаження
3. Відкиньте вказівник назад до вказівника вашого типу.

Існуючі реалізації (включаючи Boost.Addressof) роблять саме це, лише доглядаючи constта volatileкваліфікацію.

Хитрість boost::addressofі реалізація, яку надає @Luc Danton, покладаються на магію reinterpret_cast; стандарт прямо в § 5.2.10 ¶10 чітко зазначає, що

Вираз типу lvalue T1може бути передано типу "посилання на T2", якщо вираз типу "покажчик на T1" можна явно перетворити на тип "покажчик на T2", використовуючи a reinterpret_cast. Тобто, відсилка посилань reinterpret_cast<T&>(x)має той же ефект, що й перетворення *reinterpret_cast<T*>(&x)із вбудованими &та *операторами. Результатом є значення lvalue, яке посилається на той самий об'єкт, що і джерело lvalue, але з іншим типом.

Тепер це дозволяє нам перетворити довільну посилання на об'єкт на char &(з кваліфікацією cv, якщо посилання має кваліфікацію cv), оскільки будь-який вказівник може бути перетворений на (можливо, cv-кваліфікований) char *. Тепер, коли у нас є char &, перевантаження оператора на об'єкт вже не має значення, і ми можемо отримати адресу з вбудованим &оператором.

Реалізація прискорення додає декілька кроків для роботи з об'єктами, що мають кваліфікацію cv: перший reinterpret_castробиться для const volatile char &, інакше звичайний char &кастинг не працює для constта / або volatileпосилань ( reinterpret_castнеможливо видалити const). Тоді і, constі volatileвидаляється з const_cast, береться адреса &, і робиться остаточний reinterpet_castтип "правильного" типу.

const_castНеобхідно , щоб видалити const/ , volatileякі могли бути додані до неконстантному / летючим посиланнях, але це не «шкоді» , що було const/ volatileпосиланням на першому місці, тому що остаточні reinterpret_castбуде повторно додати резюме-кваліфікацію , якщо це було там на першому місці ( reinterpret_castне можна видалити, constале можна додати його).

Що стосується решти коду в addressof.hpp, то, здається, більшість із них призначена для обхідних шляхів. static inline T * f( T * v, int ), Здається, потрібно тільки для компілятора Borland, але його присутність вводить необхідність addr_impl_ref, в іншому випадку типів покажчиків будуть спіймані другий перевантаженням.

Редагувати : різні перевантаження мають різну функцію, див. @Matthieu M. відмінну відповідь .

Ну, і я вже не впевнений у цьому; Я повинен далі вивчити цей код, але зараз я готую вечерю :), я перегляну його пізніше.

Я бачив реалізацію addressofцього:

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

Не питайте мене, наскільки це відповідає!

Погляньте на boost :: addressof та його реалізацію.