Чому розмір класу в c ++ залежить від публічного / приватного статусу членів даних?

Як я знаю, розмір класу в c ++ залежить від наведених нижче факторів -

Розмір усіх нестатичних членів даних.
Порядок членів даних.
Якщо включення байтів увімкнено чи ні
Розмір його безпосереднього базового класу.
Існування віртуальних функцій.
Режим успадкування (віртуальне успадкування).

Тепер я створив 2 класи, як показано нижче -

class A{
    int a;
    short s;
    int b;
    char d;
};// kept a char at last on purpose to leave a "hole"

class B : public A{
    char c;  
};

тепер про перевірку розміру A та BI див

розмір A: 16
розмір B: 16

моє припущення, що графік класу В розміщений у "дірі", залишеній у класі А.

Але, що мене бентежить, це нижченаведений сценарій, в якому я роблю членів громадськості

class A{
    public:
    int a;
    short d;
    int b;
    char s;
};

class B : public A{
    public:
    char c;
};

Тепер розмір стає

розмір A: 16
розмір B: 20

Я, здається, не розумію причини цієї різниці.

c++ inheritance memory

— J.DOE
джерело

Чому розмір класу в c ++ залежить від публічного / приватного статусу членів даних? - Це не так. Це деталі реалізації, залежні від компілятора.

— PaulMcKenzie

То який компілятор ви використовуєте?

— Ромен

@PaulMcKenzie Насправді це так. Стандартні мандати учасників з однаковим доступом групуються так, що змінюються, що змінить стратегію заміщення компілятора.

— NathanOliver

@ NathanOliver-ReinstateMonica, я цього не знав. Чи є у вас випадково посилання на відповідний розділ?

— R

@RSahu Дивлячись на те, щоб зараз чітко поставити свою відповідь.

— NathanOliver

Itanium ABI використовує визначення C ++ 03 визначення POD для визначення класів, які є "POD для цілей компонування". Наявність членів приватних даних позбавляє класу від сукупності, а отже, POD у C ++ 03:

POD-структура не представляє собою сукупність клас , який не має не те-статичні елементи даних типу не-POD-структури, які не-POD-об'єднання (або масив таких видів) або в якості посилання, і не має ніякого певного користувачем оператор присвоювання копіювання і немає визначений користувачем деструктор.

Будучи класом POD, вимикає повторне використання хвостових накладок :

Розмір dsize, nvsize та nvalign цих типів визначається як їх звичайний розмір та вирівнювання. Ці властивості мають значення лише для непорожніх типів класів, які використовуються як базові класи. Ми ігноруємо прокладку хвоста для POD, оскільки рання версія стандарту не дозволила нам використовувати його для чого-небудь іншого і тому, що іноді дозволяє швидше копіювати тип.

Таким чином, у вашому першому прикладі Aце не POD для цілей компонування, і його хвостові накладки можна використовувати B::c, але у вашому другому прикладі це POD, і його хвостові накладки неможливо повторно використовувати.

— ТС
джерело