Вычисление этого указателя содержащего объекта

Question

Вычисление этого указателя содержащего объекта

0

Является ли следующая портативная и стандартно-совместимая C++, всегда возвращающая "успех"?

#include <iostream>
#include <cstddef>

struct Containing {
    struct {
        Containing * get_containing () {
            return reinterpret_cast<Containing *> (
                (char *) this - offsetof (Containing, inner)
            );
        }
    } inner;
};


int main () {
    Containing c;
    std::cout
        << (c.inner.get_containing () == &c ? "success" : "fail")
        << std::endl;
}

JohnB 25 дек. 2013, в 15:38

Источник

0

Хорошо, я удалил возможно повторяющийся вопрос. Мой единственный вопрос: "Это соответствует стандартам или нет?" Кстати, голосование за «повторяющиеся вопросы» начинает делать Stackoverflow бесполезным, так как люди, голосующие за закрытие, похоже, не читают того, о чем спрашивали.
JohnB 25 дек. 2013, в 14:37
1

Я прочитал то, что спросили;) Тем не менее, теперь я отозвал закрытое голосование, так как редактирование означает, что больше нет реального перекрытия ...
Oliver Charlesworth 25 дек. 2013, в 14:38
0

Кстати, вот немного более сложный пример, который терпит неудачу: ideone.com/2sr2JF . Вам нужно добавить несколько приведений к char * чтобы сделать эту работу более общей (несмотря на UB).
Oliver Charlesworth 25 дек. 2013, в 14:39
0

Спасибо. Кажется, достаточно, чтобы бросить this .
JohnB 25 дек. 2013, в 14:46
0

Что вы имеете в виду, вычисляя «этот указатель»? Вы пытаетесь получить VTable? Для этого вы можете просто сделать: DWORD* VTable = *reinterpret_cast<DWORD**>(&SomeInstance); .. Опять же, я не уверен, что это то, что вы хотите ..
Brandon 25 дек. 2013, в 15:20
0

@CantChooseUsernames: Кажется, довольно ясно, что он хочет this , но для содержащего экземпляра.
Oliver Charlesworth 25 дек. 2013, в 15:21
0

Тогда какой смысл смещения? Почему бы просто не вернуть «это»? Зачем это делать, когда он может просто сделать &instance ?
Brandon 25 дек. 2013, в 15:22
0

@CantChooseUsernames: Потому что это было бы this для внутреннего класса.
Oliver Charlesworth 25 дек. 2013, в 15:59
0

По стандарту: «Отображение, выполняемое reinterpret_cast <>, определяется реализацией».
n.m. 25 дек. 2013, в 16:02
0

@OliCharlesworth ideone.com/csqQ1F <--- Это я и имею в виду. OP проделывает довольно много времени, чтобы вычислить «этот указатель», когда он уже есть ... Я думаю, он бы нуждался в этом, если сам класс хочет адрес, но это не имеет особого смысла или кажется, что его много используют.
Brandon 25 дек. 2013, в 16:07
0

@CantChooseUsernames: Это похоже на код OP, но без приведения.
Oliver Charlesworth 25 дек. 2013, в 16:10
0

Вы правы. Не заметил , что &c.inner такое же , как &c которой так же , как c.inner.get_containing() , которая является такой же , как this . В этом случае какой смысл get_containing() ? OP может вернуть this из get_containing() . ideone.com/UjJpZY
Brandon 25 дек. 2013, в 16:13
0

@CantChooseUsernames: Да, я думаю, это вырожденный случай, потому что offsetof(inner) == 0 . Я полагаю, что ОП хочет более общий случай, когда &outer != &inner .
Oliver Charlesworth 25 дек. 2013, в 16:17
0

возможный дубликат stackoverflow.com/questions/20395008/…
Jarod42 25 дек. 2013, в 16:44

Показать ещё 12 комментариев

Теги:

c++

inner-classes

pointer-arithmetic

1 ответ

Ещё вопросы

Хорошо, я удалил возможно повторяющийся вопрос. Мой единственный вопрос: "Это соответствует стандартам или нет?" Кстати, голосование за «повторяющиеся вопросы» начинает делать Stackoverflow бесполезным, так как люди, голосующие за закрытие, похоже, не читают того, о чем спрашивали.
Я прочитал то, что спросили;) Тем не менее, теперь я отозвал закрытое голосование, так как редактирование означает, что больше нет реального перекрытия ...
Кстати, вот немного более сложный пример, который терпит неудачу: ideone.com/2sr2JF . Вам нужно добавить несколько приведений к char * чтобы сделать эту работу более общей (несмотря на UB).
Спасибо. Кажется, достаточно, чтобы бросить this .
Что вы имеете в виду, вычисляя «этот указатель»? Вы пытаетесь получить VTable? Для этого вы можете просто сделать: DWORD* VTable = *reinterpret_cast<DWORD**>(&SomeInstance); .. Опять же, я не уверен, что это то, что вы хотите ..
@CantChooseUsernames: Кажется, довольно ясно, что он хочет this , но для содержащего экземпляра.
Тогда какой смысл смещения? Почему бы просто не вернуть «это»? Зачем это делать, когда он может просто сделать &instance ?
@CantChooseUsernames: Потому что это было бы this для внутреннего класса.
По стандарту: «Отображение, выполняемое reinterpret_cast <>, определяется реализацией».
@OliCharlesworth ideone.com/csqQ1F <--- Это я и имею в виду. OP проделывает довольно много времени, чтобы вычислить «этот указатель», когда он уже есть ... Я думаю, он бы нуждался в этом, если сам класс хочет адрес, но это не имеет особого смысла или кажется, что его много используют.
@CantChooseUsernames: Это похоже на код OP, но без приведения.
Вы правы. Не заметил , что &c.inner такое же , как &c которой так же , как c.inner.get_containing() , которая является такой же , как this . В этом случае какой смысл get_containing() ? OP может вернуть this из get_containing() . ideone.com/UjJpZY
@CantChooseUsernames: Да, я думаю, это вырожденный случай, потому что offsetof(inner) == 0 . Я полагаю, что ОП хочет более общий случай, когда &outer != &inner .
возможный дубликат stackoverflow.com/questions/20395008/…

Cheers and hth. - Alf · Accepted Answer · 2013-12-25T15-26-00.000Z

#include <iostream>
#include <cstddef>

struct Containing {
    struct {
        Containing * get_containing () {
            return reinterpret_cast<Containing *> (
                (char *) this - offsetof (Containing, inner)
            );
        }
    } inner;
};


int main () {
    Containing c;
    std::cout
        << (c.inner.get_containing () == &c ? "success" : "fail")
        << std::endl;
}

Указанный код, который я повторил выше, в порядке, потому что reinterpret_cast в/из первого элемента POD поддерживается для совместимости C.

Как я помню, C++ 11 расширил набор типов, в которых работает reinterpret_cast.

Однако, как только вы вводите виртуальную функцию или другие вещи, отличные от POD'', вы превышаете рабочий режим offsetof, а также гарантируете reinterpret_cast.

Стандард. Используя функцию "Найти" в моем PDF-читателе, применяемую к документу [N3290.pdf] (окончательный вариант C++ 11, идентичный стандарту), тремя щелчками мыши была предложена следующая информация о offsetof:

C++ 11 §18.2/4:
"Макрос offsetof (тип, член-обозначение) принимает ограниченный набор аргументов типа в этом международном стандарте. Если тип не является стандартным классом макета (раздел 9), результаты не определены".

Аналогично, нажав на заголовок раздела 9 "Классы", а затем попросив читателя PDF выполнить поиск reinterpret_cast, я обнаружил...

C++ 11 9.2/20:
"Указатель на объект структуры стандартного макета, соответствующим образом преобразованный с использованием reinterpret_cast, указывает на его начальный член (или если этот элемент является битовым полем, а затем в единицу, в которой он находится) и наоборот"

На практике. Использование offsetof для первого элемента бит бессмысленно, поскольку оно гарантируется при смещении 0 (без дополнений до). Чтобы сделать эту вещь значимой, вы должны понимать логическое обобщение данного кода, где...

Соответствующий член не является первым членом.
Арифметика указателя выполняется с указателем на байт (например, char).

Затем для типов POD или C++ 11 более общий стандартный макет, offsetof отлично, но reinterpret_cast нуждается в конкретной поддержке компилятора. С Visual C++ все в порядке. С помощью g++ вам лучше либо, по возможности, отключить его глупые предупреждения и связанные с ними глупые оптимизации, либо сделать обход через указатель void.

Exeeding пределы offsetof не вообще хорошая идея. Например, с виртуальным наследованием смещения могут широко варьироваться, а не выводиться из информации только статического типа.