Почему встроенные конструкторы и деструкторы не являются хорошей идеей в С++?
Я помню, как читал в одной из книг на С++ (довольно давно), что неплохо иметь встроенные конструкторы и деструкторы, особенно для производного класса.
Я понимаю, что inlining может вызвать некоторое раздувание объектного кода, но есть ли другие конструктивные соображения, которые препятствуют встроенным конструкторам и деструкторам? Конечно, большинство компиляторов могут отклонить inline и продолжить создание тела функции, но если они должны были установить, какое наказание можно заплатить?
Ответы
Ответ 1
Компилятор является бесплатным встроенным кодом, который вы не объявили встроенным, и не содержит встроенного кода, который вы объявили inline. Я видел, как компиляторы выполняют обе эти вещи. Из-за этого ключевое слово inline не означает, что большинство людей думает, что это так. Это означает, что разрешено исключение из одного правила определения, поэтому вы можете помещать функции и т.д. В файл заголовка и не получать ошибки компоновщика.
Итак, совет - мусор, пусть компилятор решит, что лучше всего встроить, а что нет. Вставьте туда, где вам нужно, чтобы предотвратить ошибки компоновщика, вот и все.
Ответ 2
Нет абсолютно никакой причины избегать встроенных конструкторов и деструкторов. Книга неверна, так как ошибочно может быть.
Ответ 3
Помимо причины, которую @oli упоминает в своем ответе:
Книга, вероятно, ведет к тому, что не встроены конструкторы и деструкторы, потому что даже кажущиеся тривиальные или пустые функции могут часто содержать много неявно сгенерированного кода компилятором, а определение фактической функции может оказаться довольно большим. Это может привести к разрыву кода,
Сказав это, разумно позволить компилятору фактически решить, включать ли встроенный или не встроенный вызов функции (даже конструкторы и деструкторы), большинство современных компиляторов дня будут соответствующим образом оптимизировать функции с помощью подкладки.
Ответ 4
Я не знаю о конструкторах, но деструкторы очень часто virtual
. В большинстве случаев компилятор не имеет смысла встроить виртуальные функции, поскольку он не известен до тех пор, пока не будет вызвано время выполнения, которое будет отменено.
Ответ 5
Я уверен, что это не о том, что С++ делает с кодом, потому что, как сказано, это всего лишь намек.
Если вы начнете смотреть на соображения проектирования программного обеспечения, все изменится. Все изменения встроенных функций заставят перекомпилировать все зависимые файлы.
Ухудшается, когда вы поддерживаете библиотеку и хотите отправить версию исправления ошибок, оставаясь совместимой с ABI. Встроенные функции просто не могут быть заменены другой версией, потому что код вызова не может быть перекомпилирован. Поэтому, когда ваша не-встроенная функция может быть заменена по желанию, вам придется перейти к новой версии вашего интерфейса, когда встроенные функции будут изменены.
Объедините это с тем фактом, что конструкторы редко могут быть встроены в компилятор, тогда вы можете себе представить, почему книга дала бы упомянутый совет.