Коли використовувати вбудовану функцію, а коли її не використовувати?

Я знаю, що inline - це підказка або запит до компілятора і використовується для уникнення накладних викликів функцій.

Тож на якій основі можна визначити, є функція кандидатом на вбудоване чи ні? У якому випадку слід уникати вкладки?

Уникнути вартості функціонального дзвінка - це лише половина історії.

робити:

• використовувати inlineзамість#define
• дуже маленькі функції - хороші кандидати для inline: швидшого коду та менших виконуваних файлів (більше шансів залишитися в кеш-коді)
• функція невелика і викликається дуже часто

не:

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

розробляючи бібліотеку, щоб зробити клас розширюваним у майбутньому, слід:

• додайте нелінійний віртуальний деструктор, навіть якщо тіло порожнє
• зробити всі конструктори нелінійними
• писати не вбудовані реалізації конструктора копіювання та оператора присвоєння, якщо клас не може бути скопійований за значенням

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

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

Список літератури:

• Вбудовувати чи не вбудовувати
• [9] Вбудовані функції
• Політика / проблеми бінарної сумісності з C ++
• GotW № 33: Inline
• Інлайн Редукс
• Ефективний C ++ - Пункт 33: Використовуйте інлігінг розумно

EDIT: Bjarne Stroustrup, Мова програмування на C ++:

Функція може бути визначена як inline. Наприклад:

inline int fac(int n)
{
  return (n < 2) ? 1 : n * fac(n-1);
}

Специфікатор inlineє натяком компілятору, що він повинен намагатися генерувати код для fac()вбудованого виклику, а не встановлювати код для функції один раз, а потім викликати через звичайний механізм виклику функції. Розумний компілятор може генерувати константу 720для дзвінка fac(6). Можливість взаємно рекурсивних вбудованих функцій, вбудованих функцій, які повторюються або не залежать від введення тощо, не дає можливості гарантувати, що кожен виклик inlineфункції насправді є вкладеним. Ступінь чіткості компілятора не може бути законодавчо встановлений, тому один компілятор може генерувати 720, інший 6 * fac(5), а ще один невкладений дзвінок fac(6).

Щоб зробити вбудовування можливим за відсутності незвично розумних засобів компіляції та зв’язування, визначення - а не лише декларування - функції вбудованої функції повинно бути в межах сфери (§ 9.2). inlineEspecifier не впливає на семантику функції. Зокрема, вбудована функція все ще має унікальну адресу і тому має staticзмінні (§ 7.1.2) вбудованої функції.

EDIT2: ISO-IEC 14882-1998, 7.1.2 Специфікатори функції

Оголошення функції (8.3.5, 9.3, 11.4) із inlineспецифікатором оголошує вбудовану функцію. Вбудований специфікатор вказує на реалізацію, що заміна вбудованого функції функції в точці виклику повинна віддавати перевагу звичайному механізму виклику функції. Не потрібно реалізовувати для виконання цієї заміни вбудовані в точці виклику; однак, навіть якщо ця заміна вбудованої лінії опущена, інші правила для функцій вбудованого рівня, визначені 7.1.2, все ще повинні дотримуватися.

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

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

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

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

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

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

Найкращий спосіб дізнатися це - профілювати свою програму та відзначати невеликі функції, які називаються багато разів і записуються через цикли процесора inline. Ключове слово тут "мале" - коли накладні витрати виклику функцій є незначними порівняно з часом, проведеним у функції, їх безглуздо вбудовувати.

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

Передчасна оптимізація - корінь усього зла!

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

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

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

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

ви можете прочитати більше про рядки у файлі c ++

Я часто використовую вбудовані функції не як оптимізацію, а щоб зробити код читабельнішим. Іноді сам код коротший і простіший для розуміння, ніж коментарі, описові назви тощо. Наприклад:

void IncreaseCount() { freeInstancesCnt++; }

Читач одразу знає повну семантику коду.

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

Найкращим способом було б вивчити та порівняти згенеровані інструкції для вбудованих та не накреслених. Однак опускати це завжди безпечно inline. Використання inlineможе призвести до проблем, яких ви не хочете.

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

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

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

• Короткі підпрограми, які називаються в тісній петлі.
• Дуже основні функції аксесуарів (get / set) та обгортки.
• Код шаблону у файлах заголовка, на жаль, автоматично отримує підказку вбудованого.
• Короткий код, який використовується як макрос. (Наприклад, min () / max ())
• Короткі математичні процедури.

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

Коли inlineметод переноситься у вихідний файл і більше не вказується, весь проект повинен бути перебудований (принаймні, це був мій досвід). А також коли методи перетворюються на вбудовані.

Використовувати класифікатор вбудованої функції слід лише тоді, коли код функції невеликий. Якщо функцій більше, то вам слід віддати перевагу нормальним функціям, оскільки економія в просторі пам’яті варто порівняно невеликої жертви у швидкості виконання.

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

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

Правило, яке я використовую, - це не використовувати вбудований, якщо тільки я не хочу, щоб воно було вбудованим. Виглядає дурно, тепер пояснення.

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

Я знаю, що inline - це підказка або запит до компілятора

Насправді inlineце замовлення для компілятора, він не має вибору і після inlineключового слова робить весь код вбудованим. Таким чином, ви ніколи не можете використовувати inlineключове слово, і компілятор створить найкоротший код.

То коли використовувати inline?

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

Наприклад, у мене є така функція:

inline bool ValidUser(const std::string& username, const std::string& password)
{
    //here it is quite long function
}

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