public:
inline int GetValue() const {
return m_nValue;
}
inline void SetValue(int nNewValue) {
this -> m_nValue = nNewValue;
}
На Learn C ++ вони сказали, що це буде працювати швидше. Отже, я подумав, що було б чудово використовувати на геттерах та сеттерах. Але, можливо, є деякі недоліки?
Відповіді:
Я нічого не вкладаю, поки профіліст спеціально не сказав мені, що не вбудова призводить до проблеми з продуктивністю.
Компілятор C ++ дуже розумний і майже напевно автоматично вбудовує таку просту функцію, як ця для вас. І, як правило, це розумніше, ніж ти, і буде робити набагато кращу роботу, визначаючи, що слід чи що не слід вкладати.
Я б не думав про те, що робити чи ні, і зосередитись на вирішенні. inlineПізніше додати ключове слово (що не є гарантією вбудованого до речі) дуже просто, і потенційні місця можна легко знайти за допомогою профілювача.
Якщо ви пишете їх всередині визначення, вони вважаються inline за замовчуванням .
Це означає, що вони будуть дозволені в декількох одиницях компіляції (оскільки самі визначення класів, як правило, з'являються в декількох одиницях компіляції), а не те, що вони насправді будуть вбудовані.
inlineякщо вони визначені у визначенні класу, яке майже повністю не пов'язане з компілятором / компонувальником, що вкладає функцію.
Це погана практика у відкритих API. Будь-яка зміна цих функцій вимагає перекомпіляції всіх клієнтів.
Загалом наявність геттерів та сетерів демонструє погану абстракцію, не робіть цього. Якщо ви постійно переходите до необроблених даних в іншому класі, то вам, ймовірно, доведеться перевпорядкувати свої класи, замість цього подумайте, як ви хочете маніпулювати даними в класі, та надайте відповідні методи для цього.
Негативні моменти:
Компілятор може вільно ігнорувати вас.
Будь-яка зміна цих функцій вимагає перекомпіляції всіх клієнтів.
Хороший компілятор все одно вставить невбудовані функції, коли це доречно.
Я також хотів би додати, що якщо ви не виконуєте мільйони наборів / наборів за кадр, це майже не має значення, вбудовані вони чи ні. Чесно кажучи, не варто втрачати сон.
Крім того, майте на увазі, що те, що ви поставили слово "вбудований" перед декларацією + визначенням, не означає, що компілятор вбудує ваш код. Він використовує різні евристики, щоб з’ясувати, чи має це сенс, що часто є класичним компромісом швидкості проти розміру. Однак існує ключове слово "__forceinline" за наймом у VC ++ (я не впевнений, що це в GCC), яке накладає увагу на фантастичну евристику компіляторів. Я насправді не рекомендую це взагалі, і, крім того, як тільки ви перенесете іншу архітектуру, це, швидше за все, буде неправильним.
Спробуйте помістити всі визначення функцій у файл реалізації та залиште чисті декларації для заголовків (якщо, звичайно, ви не метапрограмуєте шаблон (STL / BOOST / і т. Д.), І в цьому випадку майже все є в заголовках;))
Одне з класичних місць, які люди люблять вбудовувати (принаймні у відеоіграх, звідки я родом), - це математичні заголовки. Продукти з перехрещенням / крапками, довжини векторів, очищення матриці тощо часто розміщуються в заголовку, що, на мою думку, є непотрібним. 9/10 це не має значення для продуктивності, і якщо вам коли-небудь потрібно буде зробити щільний цикл, наприклад, перетворення великого векторного масиву за допомогою якоїсь матриці, вам, мабуть, краще вручну робити математику вбудовано або навіть краще її кодувати в асемблер для певної платформи.
О, і ще один момент, якщо ви відчуваєте, що вам дійсно потрібен клас, щоб мати більше даних, ніж код, подумайте про використання старої доброї структури, яка не приносить із собою багажу абстракції OO, для цього він і існує. :)
Вибачте, не мав на увазі продовжувати так багато, але я просто думаю, що це допомагає розглядати випадки використання в реальному світі, і не занадто зациклюватися на педантичних налаштуваннях компілятора (повірте мені, я був там;))
Удачі.
Шейн
Код буде компілюватися трохи довше, і ви втратите інкапсуляцію. Все залежить від розміру проекту та його характеру. У більшості випадків можна зробити їх вбудованими, якщо вони не мають жодної складної логіки.
До речі, ви можете пропустити, inlineякщо реалізуєте безпосередньо у визначенні класу.
Вбудоване ключове слово безглуздо у вашому випадку
Компілятор вбудовує вашу функцію, якщо може і хоче, незалежно від ключового слова.
Ключове слово inline впливає на посилання, а не на вбудовування. Це трохи заплутано, але прочитайте це.
Якщо визначення знаходиться в іншому блоці компіляції (в основному вихідний файл після препроцесора), ніж виклик, вбудовування буде можливим лише за умови, що ввімкнена оптимізація цілого проекту та генерація коду часу зв’язку. Увімкнення цієї функції значно збільшує час зв’язування (оскільки вона практично перекомпілює все в компонувальнику), але, очевидно, може покращити продуктивність. Не впевнений, увімкнено чи вимкнено за замовчуванням у GCC та VS.
Я б сказав, що вам не потрібно цим займатися. Прочитайте розділ поширених запитань про вбудовування .
Треба сказати, у мене немає сильного відрази до цієї практики, якої, здається, мають інші учасники цієї теми. Я погоджуюсь з тим, що приріст продуктивності від вставки є незначним у всіх випадках, крім найбільш широко використовуваних. (І так, я маю стикався з такими випадками на практиці.) Де я такий роду вбудовування, я роблю це для зручності, і як правило , тільки для дотепів , як це. У більшості випадків мого використання потреба уникати перекомпіляції на стороні клієнта, якщо я коли-небудь їх змінюю, просто не така сильна.
Так, ви можете відмовитися від цього inline, як це передбачається розміщенням реалізації.
Крім того, я трохи здивований бурхливістю щодо аксесуарів. Ви навряд чи можете чхнути на клас будь-якою мовою ОО, не підірвавши кілька, і вони, врешті-решт, є допустимою технікою для абстрагування реалізації від інтерфейсу, тому трохи мазохістично заявляти про них як про погану практику ОО. це є хорошим рада не аксессор записи без розбору, але я також раджу не захоплюватися в прагненні викоренити їх.
Візьміть це, пуристи. :-)