Réponse.

POD (Plain Old Data) est une structure ou un type de données en C++ qui est compatible avec la structuration des données d'une manière classique comme en C et est parfaitement adapté à la programmation bas niveau.

Historique de la question:

POD a émergé comme un héritage du langage C pour garantir la compatibilité mémoire entre C et C++. Dans C++98, les objets POD avaient des restrictions strictes permettant une copie byte par byte ou une sérialisation directe.

Problème:

De nombreux programmeurs confondent POD avec de simples structures et ne tiennent pas compte des nuances de la norme, comme les règles d'agrégation ou la présence de constructeurs non standards, ce qui est critique pour la compatibilité ABI et les opérations bas niveau (memcpy, sérialisation).

Solution:

Dans le C++ moderne avec C++11, des notions comme trivial, trivially copyable et standard-layout ont été introduites pour clarifier les exigences.

POD: représentation standard, uniquement des types simples, pas de constructeurs ou destructeurs personnalisés, pas de fonctions virtuelles, pas d'héritage privé.
Trivially copyable: peut être copié via memcpy, les constructeurs et destructeurs de copie et de déplacement sont trivials.
Standard-layout: pas d'héritage virtuel, ordonnancement commun des membres, compatibilité avec l'ABI C (peut être efficacement converti en char*).

Exemple de code:

struct PODType {
    int x;
    double y;
};

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

Caractéristiques clés :

Idéaux pour la sérialisation, échange de données entre C et C++.
Ne prennent pas en charge l'encapsulation (tous les membres doivent être uniformément accessibles).
N'acceptent pas de constructeurs non standards ou d'héritage avec des fonctions virtuelles.

Questions pièges.

Peut-on faire un type POD avec des membres privés?

Non, le standard-layout exige soit que tous les membres soient publics, soit un accès uniforme (soit tous publics, soit tous privés/protégés).

Un classe sera-t-elle un type POD si elle a un constructeur utilisateur défini explicitement sans corps?

Non, la présence d'un constructeur utilisateur (même vide) rend le type non POD et non trivial.

Puis-je utiliser un type POD avec un destructeur virtuel ou des fonctions virtuelles?

Non, les méthodes virtuelles rendent le type non POD et non standard-layout.

Erreurs typiques et anti-modèles

Sérialisation ou copy-paste via memcpy non pour des objets trival/nonPOD.
Utilisation de constructeurs non standards dans des types POD, ce qui brise la compatibilité binaire.
Complexification de la structure POD, mélange de styles C et C++.

Exemple de la vie réelle

Cas négatif

Un développeur sérialise une structure via memcpy, sans remarquer qu'un std::string (non POD) a été ajouté, les données deviennent incorrectes lors de la lecture.

Avantages:

Facile à intégrer à l'étape de prototypage avec des structures C.

Inconvénients:

Bugs implicites, incompatibilité avec des objets C++.

Cas positif

L'ensemble de la structure est POD ou trival, sérialisation via memcpy, aucune référence ni conteneur std à l'intérieur.