Я читаю книгу Герба Саттера "Винятковий С ++", і в цій книзі я дізнався про ідіому pImpl. В основному, ідея полягає у створенні структури для privateоб'єктів а classта динамічно розподілити їх, щоб зменшити час компіляції (а також краще приховати приватні реалізації).

Наприклад:

class X
{
private:
  C c;
  D d;  
} ;

може бути змінено на:

class X
{
private:
  struct XImpl;
  XImpl* pImpl;       
};

та, у CPP, визначення:

struct X::XImpl
{
  C c;
  D d;
};

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

Чи варто використовувати його скрізь або з обережністю? І чи рекомендується цю техніку використовувати у вбудованих системах (де продуктивність дуже важлива)?

Отже, мені цікаво, що ця методика справді використовується на практиці? Чи варто використовувати його скрізь або з обережністю?

Звичайно, використовується. Я використовую це у своєму проекті, майже в кожному класі.

Причини використання ідіоми PIMPL:

Бінарна сумісність

Коли ви розробляєте бібліотеку, ви можете додавати / змінювати поля, XImplне порушуючи бінарної сумісності з вашим клієнтом (це може означати збої!). Оскільки двійковий макет Xкласу не змінюється, коли ви додаєте нові поля до Ximplкласу, безпечно додавати нову функціональність у бібліотеку в оновленнях незначних версій.

Звичайно, ви можете також додати нові публічні / приватні невіртуальні методи до X/ XImplбез порушення бінарної сумісності, але це нарівні зі стандартною технікою заголовка / реалізації.

Приховування даних

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

Час компіляції

Час компіляції скорочується, оскільки потрібно лише Xперебудовувати вихідний (імплементаційний) файл, коли ви додаєте / видаляєте поля та / або методи до XImplкласу (який відображає додавання приватних полів / методів у стандартній техніці). На практиці це звичайна операція.

За допомогою стандартної техніки заголовка / реалізації (без PIMPL), коли ви додаєте нове поле до Xкожного клієнта, який коли-небудь виділяє X(або в стеці, або в купі), потрібно перекомпілювати, оскільки він повинен регулювати розмір розподілу. Ну, і кожен клієнт, який ніколи не виділяє X, також повинен бути перекомпільований, але це просто накладні витрати (результат коду на стороні клієнта буде однаковим).

Більше того, стандартне розділення заголовка / реалізації XClient1.cppпотрібно перекомпілювати навіть тоді, коли приватний метод X::foo()був доданий Xта X.hзмінений, хоча, XClient1.cppможливо, не можна викликати цей метод з причини інкапсуляції! Як і вище, вона чиста накладні витрати і пов'язана з тим, як працюють системи побудови C ++ у реальному житті.

Звичайно, рекомпіляція не потрібна, коли ви просто змінюєте реалізацію методів (оскільки ви не торкаєтесь заголовка), але це нарівні зі стандартною технікою заголовка / реалізації.

Чи рекомендується цей прийом використовувати у вбудованих системах (де продуктивність дуже важлива)?

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

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

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

Переваги, які він може вам надати:

• допомагає зберігати бінарну сумісність спільних бібліотек
• приховуючи певні внутрішні деталі
• зменшення циклів рекомпіляції

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

Можливі недоліки (також тут, залежно від впровадження та чи є вони для вас реальними недоліками):

• Збільшення використання пам’яті за рахунок більшої кількості асигнувань, ніж при наївному варіанті
• збільшені зусилля з обслуговування (вам потрібно написати хоча б функції переадресації)
• втрата продуктивності (компілятор, можливо, не зможе впорядкувати вміст, як це відбувається з наївною реалізацією вашого класу)

Тож уважно дайте всім значення і оцініть самі. Для мене майже завжди виявляється, що використовувати ідіому pimpl не варто зусиль. Є лише один випадок, коли я особисто його використовую (або принаймні щось подібне):

Моя обгортка C ++ для statвиклику Linux . Тут структура із заголовка C може бути різною, залежно від того #defines, що встановлено. А оскільки мій заголовок обгортки не може контролювати їх усіх, я лише #include <sys/stat.h>в своєму .cxxфайлі та уникаю цих проблем.

Погодьтеся з усіма іншими щодо товарів, але дозвольте мені поставити доказ обмеження: не працює добре з шаблонами .

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

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

Це хороша парадигма для класичного ООП (на основі спадкування), але не для загального програмування (на основі спеціалізації).

Інші люди вже надали технічні покращення / недоліки, але я думаю, що варто зазначити наступне:

Перш за все, не будьте догматичними. Якщо pImpl працює у вашій ситуації, використовуйте його - не використовуйте його лише тому, що "це краще OO, оскільки він дійсно приховує реалізацію" тощо. Цитуючи C ++ FAQ:

інкапсуляція призначена для коду, а не людей ( джерело )

Просто для того, щоб навести приклад програмного забезпечення з відкритим кодом, де воно використовується і чому: OpenThreads, бібліотека різьблення, яку використовує OpenSceneGraph . Основна ідея полягає в тому, щоб видалити з заголовка (наприклад <Thread.h>) весь код платформи, оскільки внутрішні змінні стану (наприклад, ручки потоку) відрізняються від платформи до платформи. Таким чином можна скласти код проти вашої бібліотеки без будь-якого знання про ідіосинкразії інших платформ, оскільки все приховано.

Я б головним чином вважав PIMPL для класів, які піддаються використанню в якості API іншими модулями. Це має багато переваг, оскільки перекомпіляція змін, внесених до впровадження PIMPL, не впливає на решту проекту. Крім того, для класів API вони сприяють бінарній сумісності (зміни в реалізації модуля не впливають на клієнтів цих модулів, їх не потрібно перекомпілювати, оскільки нова реалізація має той самий бінарний інтерфейс - інтерфейс, що піддається PIMPL).

Що стосується використання PIMPL для кожного класу, я б став обережним, оскільки всі ці переваги приносяться ціною: потрібен додатковий рівень непрямості для доступу до методів реалізації.

Я думаю, що це один із найважливіших інструментів для розв’язки.

Я використовував pimpl (та багато інших ідіом з виняткового C ++) у вбудованому проекті (SetTopBox).

Особливою метою цього idoim в нашому проекті було приховати типи використання XImpl класу. Зокрема, ми використовували його, щоб приховати деталі реалізацій для різних апаратних засобів, куди втягуватимуться різні заголовки. У нас були різні реалізації класів XImpl для однієї платформи та різні для іншої. Макет класу X залишався колишнім, незалежно від платформи.

Раніше я багато використовував цю техніку, але потім виявив себе віддаленим від неї.

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

Перевагами pImpl є:

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

2. Якщо у вас набір класів (модуль) такий, що кілька класів мають доступ до одного і того ж "impl", але користувачі модуля будуть використовувати лише "відкриті" класи.

3. Немає v-таблиці, якщо це вважається поганою справою.

Недоліки, які я знайшов у pImpl (де абстрактний інтерфейс працює краще)

1. Хоча у вас може бути лише одна "виробнича" реалізація, використовуючи абстрактний інтерфейс, ви також можете створити "макет" впровадження, який працює в одиничному тестуванні.

2. (Найбільше питання). До днів jedinstve_ptr та переміщення ви мали обмежений вибір щодо зберігання pImpl. Невідкладний покажчик і у вас виникли проблеми з тим, що ваш клас не можна скопіювати. Старий auto_ptr не працюватиме з наперед оголошеним класом (не у всіх компіляторах). Тож люди почали використовувати shared_ptr, що було приємно робити ваш клас копіюваним, але, звичайно, обидві копії мали однаковий базовий спільний_птр, якого ви можете не очікувати (змінити один і обидва змінені). Таким чином, рішенням було часто використовувати необроблений покажчик для внутрішнього та зробити клас не скопіюваним, а натомість повернути його спільний_ptr. Тож два дзвінки до нових. (Насправді 3 дані старого shared_ptr дали вам другий).

3. Технічно не дуже const-коректно, оскільки constness не передається до вказівника-члена.

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

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

Ось власне сценарій, з яким я зіткнувся, де ця ідіома дуже допомогла. Нещодавно я вирішив підтримувати DirectX 11, а також мою існуючу підтримку DirectX 9 в ігровому двигуні. Двигун вже охопив більшість функцій DX, тому жоден з DX-інтерфейсів не використовувався безпосередньо; їх просто визначали в заголовках як приватних членів. Двигун використовує DLL як розширення, додаючи підтримку клавіатури, миші, джойстика та сценаріїв, як і тиждень, як і багато інших розширень. Хоча більшість цих DLL не використовували DX безпосередньо, вони вимагали знань та зв’язку з DX просто тому, що вони втягнули заголовки, які відкривали DX. Додавши DX 11, ця складність повинна була різко зрости, проте без потреби. Переміщення членів DX у Pimpl, визначений лише у джерелі, усунуло це накладення. Крім цього зменшення залежностей бібліотеки,

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

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

Так як у майже всіх дизайнерських рішень є плюси і мінуси.

Я бачу одну перевагу, яка дозволяє програмісту досить швидко виконувати певні операції:

X( X && move_semantics_are_cool ) : pImpl(NULL) {
    this->swap(move_semantics_are_cool);
}
X& swap( X& rhs ) {
    std::swap( pImpl, rhs.pImpl );
    return *this;
}
X& operator=( X && move_semantics_are_cool ) {
    return this->swap(move_semantics_are_cool);
}
X& operator=( const X& rhs ) {
    X temporary_copy(rhs);
    return this->swap(temporary_copy);
}

PS: Я сподіваюся, що я не розумію ходу семантики.