Antwort.

POD (Plain Old Data) ist eine Struktur oder Datentyp in C++, der mit der üblichen Datenstrukturierung in C kompatibel ist und sich ideal für die Systemprogrammierung eignet.

Historischer Hintergrund:

POD entstand als Erbe der Programmiersprache C, um die Speicherkonformität zwischen C und C++ zu gewährleisten. In C++98 hatten POD-Objekte strenge Einschränkungen, damit sie byteweise kopiert oder direkt serialisiert werden konnten.

Problem:

Viele Programmierer verwechseln POD mit einfacheren Strukturen und berücksichtigen nicht die Nuancen des Standards, wie z. B. die Aggregierungsregeln oder das Vorhandensein nicht standardmäßiger Konstruktoren, was entscheidend für die ABI-Kompatibilität und Low-Level-Operationen (memcpy, Serialisierung) ist.

Lösung:

In modernem C++ wurden mit C++11 die Begriffe trivial, trivially copyable und standard-layout eingeführt, um die Anforderungen klarer zu trennen.

POD: Standarddarstellung, nur einfache Typen, keine benutzerdefinierten Konstruktoren, Destruktoren, virtuellen Funktionen, privates Erbe.
Trivially copyable: kann über memcpy kopiert werden, kopierbare und verschiebbare Konstruktoren sowie Destruktoren sind trivial.
Standard-layout: kein virtuelles Erbe, gemeinsame Anordnung der Mitglieder, Kompatibilität mit C ABI (sicher in char* umwandelbar).

Beispielcode:

struct PODType {
    int x;
    double y;
};

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

Wichtige Eigenschaften:

Ideal für Serialisierung, Datenaustausch zwischen C und C++.
Unterstützen keine Kapselung (alle Mitglieder müssen homogen zugänglich sein).
Erlauben keine nicht standardmäßigen Konstruktoren oder Erbschaften mit Virtuellen.

Trickfragen.

Kann man einen POD-Typ mit privaten Mitgliedern erstellen?

Nein, standard-layout verlangt entweder, dass alle Mitglieder public sind oder homogenen Zugang (entweder alles public oder alles private/protected).

Wird eine Klasse ein POD-Typ sein, wenn sie einen explizit definierten benutzerdefinierten Konstruktor ohne Körper hat?

Nein, das Vorhandensein eines benutzerdefinierten (auch leeren) Konstruktors macht den Typ nicht POD und nicht trivial.

Kann ich einen POD-Typ mit virtuellem Destruktor oder virtuellen Funktionen verwenden?

Nein, virtuelle Methoden machen den Typ nicht POD und nicht standard-layout.

Häufige Fehler und Anti-Patterns

Serialisierung oder Copy-Paste über memcpy nicht für trivial/nonPOD-Objekte.
Verwendung von nicht standardmäßigen Konstruktoren in POD-Typen, die die binäre Kompatibilität verletzen.
Komplexität der POD-Struktur, Vermischung von C- und C++-Stilen.

Lebensbeispiel

Negativer Fall

Ein Entwickler serialisiert eine Struktur über memcpy, ohne zu bemerken, dass std::string (nicht POD) hinzugefügt wurde, wodurch die Daten beim Lesen inkorrekt werden.

Vorteile:

Einfach in der Prototyping-Phase mit C-Strukturen zu implementieren.

Nachteile:

Uneindeutige Fehler, Inkompatibilität mit C++-Objekten.

Positiver Fall

Die gesamte Struktur ist POD oder trivial, Serialisierung – über memcpy, keine Referenzen und std-Container innerhalb.