Чому ми ставимо функції приватних членів у заголовки?

Відповідь на те, чому ми розміщуємо змінні приватних членів у заголовках C ++, полягає в тому, що розмір класу повинен бути відомий у точках, де оголошуються екземпляри, щоб компілятор міг генерувати код, який належним чином переміщується навколо стека.

Чому нам потрібно ставити приватних членів у заголовки?

Але чи є підстави оголошувати приватні функції у визначенні класу?

Альтернативою була б по суті ідіома сутенера, але без зайвої непрямості.

Чи є ця мовна особливість більш ніж історичною помилкою?

Функції приватних членів можуть бути virtual, а в загальних реалізаціях C ++ (для яких використовується vtable) необхідний певний порядок та кількість віртуальних функцій, щоб їх знали всі клієнти класу. Це застосовується, навіть якщо є одна або кілька функцій віртуального члена private.

Можливо, здається, що це як "поставлення кошика перед конем", тому що вибір реалізації компілятора не повинен впливати на специфікацію мови. Однак насправді мова C ++ була розроблена одночасно з робочою реалізацією ( Cfront ), яка використовувала vtables.

Якщо ви дозволили додавати методи до класу поза його визначенням, вони можуть бути додані будь-де , у будь-якому файлі, будь-ким.

Це негайно дасть усім клієнтському коду тривіальний доступ до приватних та захищених членів даних.

Після того, як ви закінчите визначення класу, немає ніякого способу позначати деякі файли як спеціально благословенні автором для їх розширення - є просто плоскі одиниці перекладу. Отже, єдиний розумний спосіб сказати компілятору, що певний набір методів є офіційними або благословенними автором класу - це оголосити їх всередині класу.

Зауважте, що у нас є прямий доступ до пам'яті в C ++, а це означає, що взагалі тривіально створити тип тіні з тим же макетом пам'яті, що і ваш клас, додати мої власні методи (або просто зробити всі дані загальнодоступними) та reinterpret_cast. Або я можу знайти код вашої приватної функції або розібрати її. Або знайдіть адресу функції в таблиці символів та зателефонуйте або безпосередньо.

Ці специфікатори доступу не намагаються запобігти цим атакам, оскільки це неможливо. Вони лише вказують, як слід використовувати клас.

Прийнята відповідь пояснює це віртуальними приватними функціями, але це відповідає лише на одну конкретну грань питання, що значно обмеженіше, ніж те, що задала ОП. Отже, нам потрібно перефразовувати: Чому від нас потрібно оголошувати невіртуальні приватні функції у заголовках?

Інша відповідь посилається на той факт, що класи повинні бути оголошені в одному блоці - після цього вони запечатані і до них не можна додавати. Це ви б робили, пропустивши оголосити приватний метод у заголовку, а потім спробувати визначити його в іншому місці. Приємний момент. Чому деякі користувачі класу повинні мати змогу збільшувати його таким чином, що інші користувачі не можуть спостерігати? Приватні методи є частиною цього і не виключаються з цього. Але тоді ви запитуєте, чому вони включені, і це здається трохи тавтологічним. Чому користувачі класу повинні знати про них? Якщо їх не було видно, користувачі не змогли б додати жодного, і він готовий.

Отже, я хотів надати відповідь, яка замість того, щоб включати приватні методи за замовчуванням, дає конкретні моменти на користь того, щоб вони були видимі для користувачів. Механістична причина невіртуальних приватних функцій, що вимагають публічного декларування, наведена у статті Herb Sutter's GotW № 100 про ідіому Pimpl як частину її обґрунтування. Я не буду продовжувати про Pimpl тут, оскільки я впевнений, що ми всі про це знаємо. Але ось відповідний біт:

У C ++, коли що-небудь у визначенні класу файлів заголовка змінюється, усі користувачі цього класу повинні бути перекомпільовані - навіть якщо зміна стосувалася лише приватних членів класу, до яких користувачі цього класу навіть не можуть отримати доступ. Це пояснюється тим, що модель побудови C ++ заснована на текстовому включенні і тому, що C ++ передбачає, що абоненти знають дві основні речі про клас, на який можуть вплинути приватні члени:

• Розмір і макет : [про членів і віртуальних функцій - зрозуміло і чудово для роботи, але не для того, щоб ми тут]
• Функції : Код, що викликає, повинен мати можливість вирішувати виклики до функцій учасників класу, включаючи недоступні приватні функції, які перевантажують неприватні функції - якщо приватна функція краще відповідає, викликовий код не вдасться скомпілювати. (C ++ прийняв цілеспрямоване дизайнерське рішення провести вирішення перевантаження перед перевіркою доступності з міркувань безпеки. Наприклад, вважалося, що зміна доступності функції з приватної на публічну не повинна змінювати значення юридичного коду виклику.)

Звісно, ​​Саттер є надзвичайно надійним джерелом як члена Комітету, тому він знає "обдумане дизайнерське рішення", коли його бачить. І думка вимагати публічного декларування приватних методів як способу уникнути зміненої семантики або випадково порушеної доступності пізніше - це, мабуть, найбільш переконливе обґрунтування. Вдячно, тому що вся справа здавалася досить безглуздою раніше!

Для цього є дві причини.

По-перше, зрозумійте, що специфікатор доступу призначений для компілятора , і не є актуальним під час виконання. Доступ до приватного члена поза сферою дії - помилка компіляції .

Лаконічність

Розглянемо функцію, коротку, один або два рядки. Він існує для зменшення реплікації коду в іншому місці, що також має перевагу в тому, що можна змінювати, як працює алгоритм або що-небудь інше в одному місці замість багатьох (наприклад, зміна алгоритму сортування).

Ви б хотіли мати швидкий один або два рядки в заголовку, або мати там прототип функції плюс десь реалізація? Це легше знайти в заголовку, а для коротких функцій набагато більш багатослівним є окрема реалізація.

Є ще одна основна перевага, яка ...

Вбудовані функції

Приватна функція може бути впорядкованою, і це обов'язково вимагає, щоб вона була в заголовку. Врахуйте це:

class A {
  private:
    inline void myPrivateFunction() {
      ...
    }

  public:
    inline void somePublicFunction() {
      myPrivateFunction();
      ...
    }
};

Приватна функція може бути впорядкована разом із загальнодоступною функцією. Це робиться на розсуд компілятора, оскільки inlineключове слово технічно є пропозицією , а не вимогою.

Ще одна причина наявності приватних методів у файлі заголовка: Є випадки, коли публічний вбудований метод не набагато більше, ніж викликати один або кілька приватних методів. Наявність приватних методів у заголовку означає, що виклик до загальнодоступного методу може бути повністю прив'язаний до фактичного коду приватних методів, а вбудовування не припиняється при виклику до приватного методу. Навіть з іншої одиниці компіляції (а загальнодоступні методи зазвичай називаються з різних компіляційних одиниць).

Звичайно, також є причина, що компілятор не може виявити проблеми з роздільною здатністю перевантаження, якщо він не знає всіх методів, включаючи приватні.

Це дозволяє дозволити цим функціям отримати доступ до приватних членів. В іншому випадку вам все friendодно знадобиться їх у заголовку.

Якщо будь-яка функція могла отримати доступ до приватних членів класу, то приватне було б марним.