Respuesta.

POD (Plain Old Data) es una estructura o tipo de datos en C++ que es compatible con la estructuración de datos tradicional en C y es ideal para programación de bajo nivel.

Historia del asunto:

POD surgió como un legado del lenguaje C para garantizar la compatibilidad de memoria entre C y C++. En C++98, los objetos POD tenían restricciones estrictas para que pudieran ser copiados byte a byte o serializados directamente.

Problema:

Muchos programadores confunden POD con simples estructuras y no consideran los matices del estándar, como las reglas de agregación o la presencia de constructores no estándar, que son críticos para la compatibilidad ABI y las operaciones de bajo nivel (memcpy, serialización).

Solución:

En C++ moderno, desde C++11, se introdujeron conceptos como trivial, trivially copyable y standard-layout, separando los requisitos de manera más clara.

POD: representación estándar, solo tipos simples, sin constructores o destructores personalizados, funciones virtuales, herencia privada.
Trivially copyable: se puede copiar mediante memcpy, los constructores y destructores de copia y movimiento son triviales.
Standard-layout: sin herencia virtual, orden común en la colocación de miembros, compatibilidad con C ABI (se puede convertir de forma segura a char*).

Ejemplo de código:

struct PODType {
    int x;
    double y;
};

static_assert(std::is_pod<PODType>::value, "Debe ser POD");
static_assert(std::is_trivially_copyable<PODType>::value, "Trivially copyable");
static_assert(std::is_standard_layout<PODType>::value, "Standard layout");

Características clave:

Ideales para serialización, intercambio de datos entre C y C++.
No soportan encapsulamiento (todos los miembros deben ser accesibles de manera homogénea).
No permiten constructores no estándar, herencia con virtuales.

Preguntas engañosas.

¿Se puede hacer un tipo POD con miembros privados?

No, el standard-layout requiere que todos los miembros sean públicos o un acceso homogéneo (o todos públicos, o todos privados/protegidos).

¿Será un clase un tipo POD si tiene un constructor personalizado definido explícitamente sin cuerpo?

No, la presencia de un constructor personalizado (incluso vacío) hace que el tipo no sea POD y no trivial.

¿Puedo usar un tipo POD con un destructor virtual o funciones virtuales?

No, los métodos virtuales hacen que el tipo no sea POD y no standard-layout.

Errores comunes y anti-patrones

Serialización o copia a través de memcpy no para objetos trival/nonPOD.
Uso de constructores no estándar en tipos POD, lo que rompe la compatibilidad binaria.
Complicar la estructura POD, mezclando el estilo de C y C++.

Ejemplo de la vida real

Caso negativo

Un desarrollador serializa una estructura mediante memcpy, sin notar que se ha añadido un std::string (no POD), los datos se vuelven incorrectos al leer.

Ventajas:

Fácil de implementar en la etapa de prototipado con estructuras C.

Desventajas:

Errores implícitos, incompatibilidad con objetos C++.

Caso positivo

Toda la estructura es POD o trivial, serialización a través de memcpy, sin referencias ni contenedores std en ella.