POD types in C++

Post by Nico Brailovsky @ 2010-04-07 | Permalink | Leave a comment

Let's say you have something like this:

typedef int A;
void x(A);
struct B {
   int b;
   B(int b) : b(b) {}
   virtual void x() = 0;
};

Regardless of what does function x do, what's the difference between A and B? Without getting too picky and leaving semantics aside, we may say there is no difference in behaviour. There's however a small gotcha there, which is completely irrelevant for C++ code but can bite you in the ass when interfacing C and C++. Would this work?

{
   A a; B b;
   // Case 1
   A p = malloc(sizeof(A));
   memcpy(p, &a, sizeof(A));
   // Case 2
   B p = malloc(sizeof(B));
   memcpy(p, &b, sizeof(B));
}

The answer is perhaps. In most cases it would work, in some cases it won't. C++ uses a vtable to dispatch virtual methods, so if I were to perform a memcpy of an object, then store it on disk and retrieve it afterwards I don't have any guarantees the vtable will still be valid. And that's leaving aside the case of objects having dynamically allocated memory themselves.

Wrapping up, the difference between A and B is simple: A is a POD (Plain Old Datatype, POJO for you Java guys) type, B is not. There are some other things non-POD objects can't do, for example this is invalid:

   B b;
   printf("%i", b);

Not only it's invalid: g++ emits a warning and then crashes on runtime (this is related to the use of vargs in functions with "..." params, but it's not important now).

Knowing what a POD object is, what would you do now if you had to persist (serialize) an std::string-like object? That's a topic for the next post.


In reply to this post, Nicolás Brailovsky » Blog Archive » Cool C++0X features III: Variadic templates, a fix for varargs commented @ 2011-04-26T09:05:06.000+02:00:

[...] POD types support [...]

Original published here.