Odpowiedź.

POD (Plain Old Data) to struktura lub typ danych w C++, który jest kompatybilny z tradycyjnym organizowaniem danych jak w C i jest idealny do niskopoziomowego programowania.

Historia problemu:

POD powstał jako dziedzictwo języka C, aby zapewnić kompatybilność pamięci między C a C++. W C++98 obiekty POD miały sztywne ograniczenia, aby można je było łatwo kopiować bajtowo lub serializować bezpośrednio.

Problem:

Wielu programistów myli POD z po prostu prostymi strukturami i nie uwzględnia niuansów standardu, takich jak zasady agregacji czy obecność niestandardowych konstruktorów, co jest krytyczne w ABI-kompatybilności i niskopoziomowych operacjach (memcpy, serializacja).

Rozwiązanie:

W nowoczesnym C++ od C++11 wprowadzono pojęcia trivial, trivially copyable oraz standard-layout, rozdzielając wymagania bardziej jasno.

POD: standardowa reprezentacja, tylko proste typy, brak konstruktorów, destruktorów, funkcji wirtualnych, dziedziczenia prywatnego.
Trivially copyable: można kopiować przez memcpy, konstruktory kopiujące i przenoszące oraz destruktory są trywialne.
Standard-layout: brak dziedziczenia wirtualnego, ogólny porządek rozmieszczania członków, kompatybilność z C ABI (można bezpiecznie rzutować na char*).

Przykład kodu:

struct PODType {
    int x;
    double y;
};

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

Kluczowe cechy:

Idealne do serializacji, wymiany danych pomiędzy C a C++.
Nie wspierają enkapsulacji (wszystkie człony muszą być jednolicie dostępne).
Nie dopuszczają niestandardowych konstruktorów, dziedziczenia z virtualami.

Pytania z pułapką.

Czy można stworzyć typ POD z prywatnymi członami?

Nie, standard-layout wymaga, aby wszyscy członkowie byli publiczni lub dostęp jednorodny (lub wszyscy publiczni, lub wszyscy prywatni/chronieni).

Czy klasa będzie typem POD, jeśli w niej jawnie zdefiniowano niestandardowy konstruktor bez ciała?

Nie, obecność niestandardowego (nawet pustego) konstruktora sprawia, że typ nie jest POD i nie jest trywialny.

Czy mogę użyć typu POD z wirtualnym destruktorem lub funkcjami wirtualnymi?

Nie, metody wirtualne robią z typu nie POD i nie standard-layout.

Typowe błędy i antywzorce

Serializacja lub copy-paste przez memcpy nie dla obiektów trival/nonPOD.
Użycie niestandardowych konstruktorów w typach POD, co łamie kompatybilność binarną.
Skomplikowanie struktury POD, mieszanie stylu C i C++.

Przykład z życia

Negatywny przypadek

Programista serializuje strukturę przez memcpy, nie zauważając, że dodano do niej std::string (nie POD), dane stają się niepoprawne przy odczycie.

Zalety:

Łatwe wdrażanie na etapie prototypowania ze strukturami C.

Wady:

Niejawne błędy, niekompatybilność z obiektami C++.

Pozytywny przypadek

Cała struktura — POD lub trival, serializacja — przez memcpy, brak odniesień i kontenerów std wewnątrz.