What Are Pod Types in C++

What are POD types in C++?

POD stands for Plain Old Data - that is, a class (whether defined with the keyword struct or the keyword class) without constructors, destructors and virtual members functions. Wikipedia's article on POD goes into a bit more detail and defines it as:

A Plain Old Data Structure in C++ is an aggregate class that contains only PODS as members, has no user-defined destructor, no user-defined copy assignment operator, and no nonstatic members of pointer-to-member type.

Greater detail can be found in this answer for C++98/03. C++11 changed the rules surrounding POD, relaxing them greatly, thus necessitating a follow-up answer here.

Can't C++ POD type have any constructor?

POD means Plain Old Data type which by definition cannot have user-defined constructor.

POD is actually an aggregate type (see the next quotation). So what is aggregate? The C++ Standard says in section §8.5.1/1,

An aggregate is an array or a class
(clause 9) with no user-declared
constructors (12.1), no private or
protected nonstatic data members
(clause 11), no base classes (clause
10), and no virtual functions (10.3).

And section §9/4 from the C++ Standard says,

[....] A POD-struct is an aggregate class that has no non-static data
members of type non-POD-struct,
non-POD-union (or array of such types)
or reference, and has no user-defined
copy assignment operator and no
user-defined destructor. Similarly, a
POD-union is an aggregate union that
has no non-static data members of type
non-POD-struct, non-POD-union (or
array of such types) or reference, and
has no user-defined copy assignment
operator and no user-defined
destructor. A POD class is a class
that is either a POD-struct or a
POD-union.

From this, its also clear that POD class/struct/union though cannot have user-defined assignment operator and user-defined destructor also.

---

There are however other types of POD. The section §3.9/10 says,

Arithmetic types (3.9.1),
enumeration types, pointer types, and
pointer to member types (3.9.2), and
cv-qualified versions of these types
(3.9.3) are collectively called scalar
types. Scalar types, POD-struct types,
POD-union types (clause 9), arrays of
such types and cv-qualified versions
of these types (3.9.3) are
collectively called POD types.

Read this FAQ : What is a "POD type"?

Plain Old Data types with private members?

In C++03, it's definitely not a POD. According to §9/4, "A POD-struct is an aggregate class ...", and according to §8.5.1/1:

An aggregate is an array or a class (clause 9) with no user-declared constructors (12.1), no private or protected non-static data members (clause 11), no base classes (clause 10), and no virtual functions (10.3)."

Under C++0x, at least as of N3090/3092, I believe it is a POD. These require only that all non-static members have the same access, not that the access is necessarily public. This is to fix a problem that I believe I was the first to point out -- in C++98/03, a vacuous access specifier leads to a problem:

struct x { 
    int a;
public:
    int b;
public:
   int c;
};

This fits the requirements of a POD struct -- but the standard still gives permission for the relative positions of b and c to be swapped because of the intervening access specifier. As a result, being a POD struct doesn't provide the layout guarantees that were intended to ensure compatibility with C structs (for the obvious example).

Non-pointer POD type in C++

This can depend on semantics of the structure. I could imagine a struct having int fields being keys into some volatile temporary data store (or cache). You still shouldn't serialize those, but you need internal knowledge about that struct to be able to tell¹.

In general, C++ lacks features for generic serialization. Making this automatic just on pointers is just a tip of the iceberg (if possibly pretty accurate in general) - it's also impossible in a generic way. C++ still has no reflection, and thus no way to check "every member" for some condition.

The realistic approaches could be:

• preprocessing the class sources before build to scan for pointers
• declaring all structs that are to be serialized with some macros that track the types
• the regular template check could be implemented for a set of known names for fields

All of those have their limitations, though, and together with my earlier reservations, I'm not sure how practical they'd be.

---

¹ This of course goes both ways; pointers could be used to store relative offsets, and thus be perfectly serializable.

Default initialization of POD types in C++

Local variables with automatic storage duration are not being initialized automatically. Since using uninitialized variables produces undefined behavior, it is a good practice to explicitly initialize your variables even when it's redundant.

About POD types that are being zero-initialized, C++03 standard 3.6.2 Initialization of non-local objects states:

§1 Objects with static storage duration (3.7.1) shall be zero-initialized (8.5) before any other initialization takes place. Zero-initialization and initialization with a constant expression are collectively called static initialization; all other initialization is dynamic initialization. Objects of POD types (3.9) with static storage duration initialized with constant expressions (5.19) shall be initialized before any dynamic initialization takes place.

So it's guaranteed by standard that POD types with static storage duration (whatever their scope is) will be zero-initialized.

POD members of a class (without explicit initialization in a constructor)

This situation is described in 12.6.2 Initializing bases and members, that states (selected parts):

If a given nonstatic data member or base class is not named by a mem-initializer-id (including the case where there is no mem-initializer-list because the constructor has no ctor-initializer), then:

— If the entity is a nonstatic data member..., and the entity class is a non-POD class, the entity is default-initialized (8.5)...

— Otherwise, the entity is not initialized...

After the call to a constructor for class X has completed, if a member of X is neither specified in the constructor’s mem-initializers, nor default-initialized, nor value-initialized, nor given a value during execution of the body of the constructor, the member has indeterminate value.

Example:

class C
{
public:
    C(int x, int z) : x(x), z(z) { }
    int x, y, z;
};

int main(void)
{
    C* c = new C(1,3);
    std::cout << c->y; // value of y is undetermined !!!
}

---

Related Topics