What’s associated between C and C++ -- POD types

  The ISO C++ Standard (ISO14882) has been on and around for almost 10 years by now, and the standard placed a huge gap between C and C++. Although C++ was said to be acting, in some aspects and concepts, as closely as C, yet compatibility with C was none of the goals for C++ to achieve. POD is an acronym which is used in the standard but not officially defined (For a compiler, the standard won’t even compile, will it?). It stands for Plain Old Data, which, the way I see it, refers to what’s called a struct in C. And we will see how C++ deals with POD types in the rest of the article.

  What is a POD type? First and foremost, we should use “struct” to specify the identifier, not “class”. If we use “class” to specify the identifier, we’ll inevitably use “public” to issue the members, which will make this type non-POD. Then, make sure that the struct must NOT contain any other non-POD types as data members. It can neither inherit from nor be inherited by other classes or structs, no matter POD or non-POD. And what’s more, virtual functions are not allowed in POD types. A brief conclusion, a POD looks just like a C struct.

  Whether you realized or not, C++ compiler treats a POD type no different than the way C compiler treats a struct. For example, the data members within a struct are presented in the order of their declarations, as is within a POD; we can copy or initialize a struct by calling memcpy or memmove, same as a POD by std::memcpy or std::memmove; the size of a struct, as well as that of a POD, equals to the summer of the size of the data members (For non-POD types, there are no such assumptions.).

  A question may arise that does a C++ compiler treat a struct and a class differently? For a struct that is a POD, yes! As is stated above, a C-struct, when it’s compiled and executed, performs a strictly-in-order layout, unaltered by the compiler; yet in a C++ class, the members are reordered by the compiler (in a way the compiler sees fit). To put it clear, there are no such guarantee that members (including data members and member functions) in a C++ class will be compiled in the order we declared it, and nor will public members be put before or after private members. For classes with virtual or pure virtual functions, (explicitly declared or inherited from another class), the place of vptr (a widely-used name for what points to a so-called virtual function table) is implementation-defined.

  So, what’s benefitted from using POD types? A POD type provides a chance for C++ programs to communicate and interoperate with C APIs. Projects that are implemented in C don’t have to be changed to fit C++. And, if we take full advantages of the C linking directives (or to say, extern "C"), the existing C code won’t even need recompiling! For writers of compilers or implementations, only one object model is needed, since the semantics for a C struct and a POD type in C++ are the same.

  There are indeed similarities and differences between C and C++. They often provide us with convenience, as well as confusion, doubt, and troubles. In the next article of this series, we will talk about type casts in C and C++.