Что плохого в использовании встроенных функций?

Я в этом сомневаюсь. Даже компилятор автоматически встраивает некоторые функции для оптимизации.

Это может увеличить размер исполняемый файл, и я не думаю компиляторы всегда будут делать они встроены, даже если вы использовали встроенное ключевое слово. (Или это другой путь вокруг, как то, что Вайбхав сказал?...)

Я думаю, что обычно нормально, если функция имеет только 1 или 2 оператора.

Редактировать: Вот что об этом говорится в документе linux CodingStyle:

Chapter 15: The inline disease

There appears to be a common misperception that gcc has a magic "make me faster" speedup option called "inline". While the use of inlines can be appropriate (for example as a means of replacing macros, see Chapter 12), it very often is not. Abundant use of the inline keyword leads to a much bigger kernel, which in turn slows the system as a whole down, due to a bigger icache footprint for the CPU and simply because there is less memory available for the pagecache. Just think about it; a pagecache miss causes a disk seek, which easily takes 5 miliseconds. There are a LOT of cpu cycles that can go into these 5 miliseconds.

A reasonable rule of thumb is to not put inline at functions that have more than 3 lines of code in them. An exception to this rule are the cases where a parameter is known to be a compiletime constant, and as a result of this constantness you know the compiler will be able to optimize most of your function away at compile time. For a good example of this later case, see the kmalloc() inline function.

Often people argue that adding inline to functions that are static and used only once is always a win since there is no space tradeoff. While this is technically correct, gcc is capable of inlining these automatically without help, and the maintenance issue of removing the inline when a second user appears outweighs the potential value of the hint that tells gcc to do something it would have done anyway.

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

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

Основным недостатком встроенных функций является то, что они могут увеличьте размер вашего исполняемого файла (в зависимости от количества экземпляров). Это может быть проблемой на некоторых платформах (например, встроенных системах), особенно если сама функция является рекурсивной.

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

Вы также должны отметить, что встроенное ключевое слово - это всего лишь запрос. Компилятор может решить не встраивать его, точно так же компилятор может сделать встроенную функцию, которую вы не определили как встроенную, если он считает, что компромисс между скоростью и размером того стоит.

Это решение обычно принимается на основе ряда вещей, таких как настройка между оптимизацией по скорости (избегает вызова функции) и оптимизацией по размеру (встраивание может вызвать раздувание кода, поэтому не подходит для больших многократно используемых функций).

с компилятором VC++ вы можете обойти это решение, используя __forceinline

ТАК вообще: Используйте встроенную функцию, если вы действительно хотите иметь функцию в заголовке, но в другом месте есть небольшой смысл, потому что, если вы собираетесь что-то от нее получить, хороший компилятор все равно сделает ее встроенной для вас.

Я согласен с другими сообщениями:

• inline может быть излишним, потому что компилятор сделает это
• встроенный может раздувать ваш код

Третий момент - это может вынудить вас раскрыть детали реализации в ваших заголовках, например,

class OtherObject;

class Object {
public:
    void someFunc(OtherObject& otherObj) {
        otherObj.doIt(); // Yikes requires OtherObj declaration!
    }
};

Без встроенного прямого объявления OtherObject было все, что вам нужно. С встроенным вашим заголовок требует определения для OtherObject.

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

Решить, когда функция достаточно мала, чтобы встраивание повысило производительность, довольно сложно. Руководство по стилю C++ от Google рекомендует встраивать только функции из 10 строк или меньше.

(Упрощенно) Пример:

Представьте себе простую программу, которая просто вызывает функцию «X» 5 раз.

Если X маленький и все вызовы встроены: потенциально все инструкции будут предварительно загружены в кэш инструкций с одним доступом к основной памяти - отлично!

Если X большой, скажем, приближается к емкости кэша инструкций:
Встраивание X потенциально может привести к однократной выборке инструкций из памяти для каждого встроенного экземпляра X.
. Если X не встроен, инструкции могут быть извлечены из памяти при первом вызове X, но потенциально могут оставаться в кеше для последующих вызовов.

Как уже упоминалось, ключевое слово inline - это только подсказка для компилятора. Фактически, большинство современных компиляторов полностью игнорируют этот намек. У компилятора есть собственная эвристика, чтобы решить, встраивать ли функцию, и, откровенно говоря, он не хочет ваших советов, большое вам спасибо.

Если вы действительно, действительно хотите сделать что-то встроенным, если вы действительно профилировали это и посмотрели на разборку, чтобы убедиться, что переопределение эвристики компилятора действительно имеет смысл, тогда это возможно:

• В VC++ используйте ключевое слово __forceinline
• В GCC используйте __attribute __ ((always_inline))

Однако ключевое слово inline имеет вторую, допустимую цель - объявление функций в файлах заголовков, но не внутри определения класса. Ключевое слово inline необходимо, чтобы компилятор не создавал несколько определений функции.

Возникла проблема со встроенной функцией - после того, как вы определили функцию в файле заголовка (что подразумевает встроенную функцию, явную или неявную путем определения тела функции-члена внутри класса), нет простого способа изменить ее, не заставляя пользователей перекомпилировать (в отличие от повторного подключения). Часто это вызывает проблемы, особенно если рассматриваемая функция определена в библиотеке, а заголовок является частью ее интерфейса.

Я не знаю, связан ли мой ответ с вопросом, но:

Будьте осторожны с очень в отношении встроенных виртуальных методов! Некоторые компиляторы с ошибками (например, предыдущие версии Visual C++) будут генерировать встроенный код для виртуальных методов, где стандартное поведение заключалось в том, чтобы ничего не делать, а идти вниз по дереву наследования и вызывать соответствующий метод.

1. Как говорили другие люди, встроенная функция может создать проблему, если код большой. Поскольку каждая инструкция хранится в определенной области памяти, поэтому перегрузка встроенной функции заставляет код запускать больше времени.

2. есть несколько других ситуаций, когда встроенный может не работать

   1. не работает в случае рекурсивной функции.
   2. Он также может не работать со статической переменной.
   3. он также не работает в случае использования цикла, переключателя и т. д. или мы можем сказать, что с несколькими операторами.
   4. И функция main не может работать как встроенная функция.

Среди других проблем со встроенными функциями, которые я видел часто чрезмерно используемыми (я видел встроенные функции из 500 строк), вам следует знать следующее:

• создавать нестабильность

  • Изменение источника встроенной функции заставляет всех пользователей заголовка перекомпилировать
  • #include проникает в клиента. Это может быть очень неприятно, если вы переработаете встроенную функцию и удалите больше не используемый заголовок, на который полагался какой-то клиент.

• размер исполняемого файла

  • Каждый раз, когда встроенная строка вставляется вместо инструкции вызова, компилятор должен сгенерировать весь код встроенной строки. Это нормально, если код функции короткий (одна или две строки), не очень хорошо, если функция длинная.
  • Некоторые функции могут производить намного больше кода, чем кажется на первый взгляд. В данном случае речь идет о «тривиальном» деструкторе класса, который имеет множество переменных-членов, не относящихся к поду (или две или 3 переменных-члена с довольно беспорядочными деструкторами). Должен быть сгенерирован вызов деструктора каждый.

• время исполнения

  • это очень зависит от кеша вашего процессора и разделяемых библиотек, но важна локальность ссылки. Если код, который вы, возможно, встраиваете, хранится в кэше процессора в одном месте, несколько клиентов могут найти код и не страдать от промаха кеша и последующей выборки из памяти (и, что еще хуже, если это произойдет, выборки с диска) . К сожалению, это один из тех случаев, когда вам действительно нужно провести анализ производительности.

Стандарт кодирования, в котором я работаю, ограничивает встроенные функции простыми сеттерами / геттерами и, в частности, говорит, что деструкторы не должны быть встроенными, если у вас нет измерений производительности, чтобы показать, что встраивание дает заметное преимущество.