I want to write an object into a sequential file using fwrite. The Class is like
class A{
int a;
int b;
public:
//interface
}
and when I write an object into a file. I am wandering that could I use fwrite( this, sizeof(int), 2, fo) to write the first two integers.
Question is: is this guaranteed to point to the start of the object data even if there may have a virtual table exist in the very beginning of the object. So the operation above is safe.
No it's not. You could use fwrite(&a, sizeof(int), 2, fo), but you shouldn't either. Just strolling over raw memory is seldom a good idea when it comes to safety, because you should not rely on specific memory layouts. Someone could introduce another variable c between a and b, without noticing that he's breaking your code. If you want to access your variables, do that explicitly. Don't just access the memory where you think the variables are or where they once were the last time you checked.
this provides the address of the object, which is not necessarily the address of the first member. The only exception are so-called standard-layout types. From the C++11 Standard:
(9.2/20) A pointer to a standard-layout struct object, suitably converted using a
reinterpret_cast, points to its initial member (or if that member is a bit-field, then to the unit in which it resides) and vice versa. [ Note: There might therefore be unnamed padding within a standard-layout struct object, but not at its beginning, as necessary to achieve appropriate alignment. — end note ]
This is the definition of a standard-layout type:
(9/7) A standard-layout class is a class that:
— has no non-static data members of type non-standard-layout class (or array of such types) or reference,
— has no virtual functions (10.3) and no virtual base classes (10.1),
— has the same access control (Clause 11) for all non-static data members,
— has no non-standard-layout base classes,
— either has no non-static data members in the most derived class and at most one base class with non-static data members, or has no base classes with non-static data members, and
— has no base classes of the same type as the first non-static data member.[108][108] This ensures that two subobjects that have the same class type and that belong to the same most derived object are not allocated at the same address (5.10).
Note that the object type does not have to be a POD – having standard-layout as defined above is sufficient. (PODs all have standard-layout, but in addition, they are trivially constructible, trivially movable and trivially copyable.)
As far as I can tell from your code, your type seems to be standard-layout (make sure access control is the same for all non-static data members). In this case, this will indeed point to the initial member. Regarding using this for the purposes of serialization, the Standard actually says explicitly:
(9/9) [ Note: Standard-layout classes are useful for communicating with code written in other programming languages. Their layout is specified in 9.2. — end note ]
Of course this does not solve all problems of serialization. In particular, you won't get portability of the serialized data (e.g. because of endianness incompatibility).
Many answers have correctly said "No". Here is some code that demonstrates why the this is never guaranteed to point to the start of the object:
#include <iostream>
class A {
public: virtual int value1() { std::cout << this << "\n"; }
};
class B {
public: virtual int value2() { std::cout << this << "\n"; }
};
class C : public A, public B {};
int main(int argc, char** argv) {
C* c = new C();
A* a = (A*) c;
B* b = (B*) c;
a->value1();
b->value2();
return 0;
}
Please note the use of this in the virtual methods.
The output can (depending on the compiler) show you that pointers a and b are different. Most likely, a will point to the start of the object, but b will not. The problem appears most easily when multiple inheritance is in use.
Writing an object to a file using fwrite is a very bad idea for many reasons.
For example if your class contains an std::vector<int> you would be saving pointers to the integers, not the integers.
For "higher-level" reasons (alignment, versioning, binary compatibility) it's also a bad idea in most cases even in C and even when the members are just simple native types.
