Почему Вы не можете использовать offsetof на структурах не-POD в C++?

Думаю, ваш класс соответствует определению POD в C ++ 0x. g ++ реализовал некоторые из c ++ 0x в своих последних выпусках. Я думаю, что VS2008 также содержит некоторые биты C ++ 0x.

Из статьи c ++ 0x в wikipedia

C ++ 0x ослабит некоторые правила в отношении определения POD.

A класс / структура считается POD, если он тривиален, стандартен и если все его нестатические члены POD.

Определен тривиальный класс или структура. как тот, который:

1. Имеет тривиальный конструктор по умолчанию. Это может использовать значение по умолчанию синтаксис конструктора (SomeConstructor () = default;).
2. Имеет тривиальный конструктор копирования, который может использовать синтаксис по умолчанию.
3. Имеет тривиальный оператор присваивания копии, который может использовать значение по умолчанию синтаксис.
4. Имеет тривиальный деструктор, который не должен быть виртуальным.

Класс или структура стандартного макета - это определяется как один, который:

1. Имеет только нестатические элементы данных, которые имеют тип стандартной компоновки.
2. Имеет одинаковый контроль доступа (общедоступный, частный, защищенный) для всех нестатические члены
3. Не имеет виртуальных функций
4. Не имеет виртуальных базовых классов
5. Имеет только базовые классы стандартного типа
6. Не имеет базовых классов того же типа, что и первый определенный не- статический member
7. Либо не имеет базовых классов с нестатическими членами, либо не имеет нестатические элементы данных в большинстве производный класс и не более одной базы класс с нестатическими членами. В сущность, может быть только один класс в иерархии этого класса, который имеет нестатические члены.

Если вы добавите, например, виртуальный пустой деструктор:

virtual ~Foo() {}

Ваш класс станет «полиморфным», то есть у него будет скрытое поле-член, которое является указателем на «vtable» который содержит указатели на виртуальные функции.

Из-за скрытого поля члена размер объекта и смещение членов не будут тривиальными. Таким образом, у вас должны возникнуть проблемы с использованием offsetof.

Для определения данных POD структуры, вот и объяснение [уже опубликовано в другом сообщении в Stack Overflow]

Что такое типы POD в C ++?

Теперь, переходя к вашему коду, он работает нормально, как и ожидалось. Это потому, что вы пытаетесь найти offsetof () для общедоступных членов вашего класса, что является допустимым.

Пожалуйста, дайте мне знать, правильный вопрос, если моя точка зрения выше, не проясняет ваши сомнения.

Обычно, когда вы спрашиваете « почему что-то не определено », вы получаете ответ «, потому что так сказано в стандарте ». Обычно рациональное решение связано с одной или несколькими причинами, например:

• трудно обнаружить статически, в каком случае вы являетесь.

• Угловые случаи трудно определить, и никто не позаботился об определении особых случаев;

• его использование в основном покрывается другими функциями;

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

Возвращаясь к смещению, вторая причина, вероятно, является доминирующей. Если вы посмотрите на C ++ 0X, где стандарт ранее использовал POD, теперь он использует «стандартный макет», «совместимый макет», «POD». позволяя более изысканные случаи. А для offsetof теперь нужны классы «стандартного макета», а именно в тех случаях, когда комитет не хотел принудительно разрабатывать макет.

Вы также должны учитывать общее использование offsetof (), которое заключается в получении значения поле, когда у вас есть указатель void * на объект. Множественное наследование - виртуальное или нет - проблематично для такого использования.

Готов поспорить, вы скомпилируете это с помощью VC ++. Теперь попробуйте с g ++ и посмотрите, как это работает ...

Короче говоря, он не определен, но некоторые компиляторы могут это допускать. У других нет. В любом случае, он непереносимый.

В C ++ вы можете получить относительное смещение следующим образом:

class A {
public:
  int i;
};

class B : public A {
public:
  int i;
};

void test()
{
  printf("%p, %p\n", &A::i, &B::i); // edit: changed %x to %p
}

Bluehorn's answer is correct, but for me it doesn't explain the reason for the problem in simplest terms. The way I understand it is as follows:

If NonPOD is a non-POD class, then when you do:

NonPOD np;
np.field;

the compiler does not necessarily access the field by adding some offset to the base pointer and dereferencing. For a POD class, the C++ Standard constrains it to do that(or something equivalent), but for a non-POD class it does not. The compiler might instead read a pointer out of the object, add an offset to that value to give the storage location of the field, and then dereference. This is a common mechanism with virtual inheritance if the field is a member of a virtual base of NonPOD. But it is not restricted to that case. The compiler can do pretty much anything it likes. It could call a hidden compiler-generated virtual member function if it wants.

In the complex cases, it is obviously not possible to represent the location of the field as an integer offset. So offsetof is not valid on non-POD classes.

In cases where your compiler just so happens to store the object in a simple way (such as single inheritance, and normally even non-virtual multiple inheritance, and normally fields defined right in the class that you're referencing the object by as opposed to in some base class), then it will just so happen to work. There are probably cases which just so happen to work on every single compiler there is. This doesn't make it valid.

Appendix: how does virtual inheritance work?

With simple inheritance, if B is derived from A, the usual implementation is that a pointer to B is just a pointer to A, with B's additional data stuck on the end:

A* ---> field of A  <--- B*
        field of A
        field of B

With simple multiple inheritance, you generally assume that B's base classes (call 'em A1 and A2) are arranged in some order peculiar to B. But the same trick with the pointers can't work:

A1* ---> field of A1
         field of A1
A2* ---> field of A2
         field of A2

A1 and A2 "know" nothing about the fact that they're both base classes of B. So if you cast a B* to A1*, it has to point to the fields of A1, and if you cast it to A2* it has to point to the fields of A2. The pointer conversion operator applies an offset. So you might end up with this:

A1* ---> field of A1 <---- B*
         field of A1
A2* ---> field of A2
         field of A2
         field of B
         field of B

Then casting a B* to A1* doesn't change the pointer value, but casting it to A2* adds sizeof(A1) bytes. This is the "other" reason why, in the absence of a virtual destructor, deleting B through a pointer to A2 goes wrong. It doesn't just fail to call the destructor of B and A1, it doesn't even free the right address.

Anyway, B "knows" where all its base classes are, they're always stored at the same offsets. So in this arrangement offsetof would still work. The standard doesn't require implementations to do multiple inheritance this way, but they often do (or something like it). So offsetof might work in this case on your implementation, but it is not guaranteed to.

Now, what about virtual inheritance? Suppose B1 and B2 both have A as a virtual base. This makes them single-inheritance classes, so you might think that the first trick will work again:

A* ---> field of A   <--- B1* A* ---> field of A   <--- B2* 
        field of A                    field of A
        field of B1                   field of B2

But hang on. What happens when C derives (non-virtually, for simplicity) from both B1 and B2? C must only contain 1 copy of the fields of A. Those fields can't immediately precede the fields of B1, and also immediately precede the fields of B2. We're in trouble.

So what implementations might do instead is:

// an instance of B1 looks like this, and B2 similar
A* --->  field of A
         field of A
B1* ---> pointer to A 
         field of B1

Although I've indicated B1* pointing to the first part of the object after the A subobject, I suspect (without bothering to check) the actual address won't be there, it'll be the start of A. It's just that unlike simple inheritance, the offsets between the actual address in the pointer, and the address I've indicated in the diagram, will never be used unless the compiler is certain of the dynamic type of the object. Instead, it will always go through the meta-information to reach A correctly. So my diagrams will point there, since that offset will always be applied for the uses we're interested in.

The "pointer" to A could be a pointer or an offset, it doesn't really matter. In an instance of B1, created as a B1, it points to (char*)this - sizeof(A), and the same in an instance of B2. But if we create a C, it can look like this:

A* --->  field of A
         field of A
B1* ---> pointer to A    // points to (char*)(this) - sizeof(A) as before
         field of B1
B2* ---> pointer to A    // points to (char*)(this) - sizeof(A) - sizeof(B1)
         field of B2
C* ----> pointer to A    // points to (char*)(this) - sizeof(A) - sizeof(B1) - sizeof(B2)
         field of C
         field of C

So to access a field of A using a pointer or reference to B2 requires more than just applying an offset. We must read the "pointer to A" field of B2, follow it, and only then apply an offset, because depending what class B2 is a base of, that pointer will have different values. There is no such thing as offsetof(B2,field of A): there can't be. offsetof will never work with virtual inheritance, on any implementation.