Мешает ли разделение кода на объявление (.h) и определение (.cpp) inline оптимизации?

@Undisputed · Регистрация: 10.06.2014

Студворк — интернет-сервис помощи студентам

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

Выходит если важна производительность, то такие хедера лучше не использовать?

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

Evg · 22.08.2017, 21:04

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

Croessmah · 22.08.2017, 21:12

Сообщение от Undisputed

Выходит если важна производительность, то такие хедера лучше не использовать?

На такой случай имеются предкомпилированные заголовки.

Сообщение от Undisputed

конечный бинарник по идее должен быть меньше

inline-функции с внешней линковкой и шаблоны сведутся
к одной реализации, остальные будут выпилены.

Evg · 22.08.2017, 21:43

Сообщение от Croessmah

На такой случай имеются предкомпилированные заголовки

Они влияют только на скорость компиляции, но не на производительность кода (ТС говорит именно о ней)

@Undisputed · 22.08.2017, 22:59 **[ТС]**

Evg,
Всмысле в один модуль? По смыслу это может быть некорректно... Может быть как модуль работающий с базой данных, а другой работает с сетью, ты предлагаешь все это оформить как один модуль?

Но я так и не понял как решить проблему которая связывает руки компилятору и не позволяет ему инлайнить(если конечно это утверждение верно, и такая проблема есть. Во всяком случае читал что есть...).

Первое что приходит в голову это не использовать .h

Убежденный · 23.08.2017, 11:53

Сообщение от Undisputed

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

Для современных компиляторов это не помеха.
Не могу не вспомнить нашу старую дискуссию с Evg по этому поводу:
реализация класса в .h файле хорошо или плохо?

Сообщение от Undisputed

Первое что приходит в голову это не использовать .h

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

@Renji · 23.08.2017, 12:10

Сообщение от Undisputed

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

Инлайн повышает производительность за счет того, что устраняются пляски с бубном необходимые перед началом выполнения функций/методов. Но так как устранять то там особо и нечего, оправдано это только для функций на полторы строчки. Вот собственно, функции на полторы строчки в хедере и остаются. А что побольше - выносится в .cpp файл.

Отдельный пункт - разделение кода на h и cpp может порождать так называемый недостижимый код. Это когда сначала компилятор скомпилировал функцию потому что "ну она же есть в cpp, может из других cpp вызывается". А потом оказалось что нигде эта функция не вызывается, так мертвым грузом и висит. На производительность это не влияет, но вес exe увеличивает. Что, правда, не особо заметно на фоне безобразия "прилинкую мегабайт stl-библиотек, потому что мне лень распиливать один шмат заранее скомпилированного кода на десяток шматиков поменьше" (че? Безобразие? Купи терабайтный винт и гигабитный инет, нищеброд!).

Evg · 23.08.2017, 12:13

Сообщение от Undisputed

Может быть как модуль работающий с базой данных, а другой работает с сетью, ты предлагаешь все это оформить как один модуль?

Нет. Я предлагаю не "оформлять в один модуль", а "оформлять в один модуль с учётом того", что какие-то фрагменты (в нашем случае inline-функции), формально не относящиеся к данному модулю, но используемые им, находятся в файле *.h другого модуля. Очевидно, что в *.h файл следует помещать то, что действительно важно с точки зрения производительности (в нашем случае inline)

Я тут всё-таки предполагаю, что ты действительно понимаешь, что такое *.h (т.е. как работает директива #include)

Сообщение от Убежденный

Я бы посоветовал в первую очередь решать архитектурные и алгоритмические вопросы

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

Не по теме:

Сообщение от Убежденный

Не могу не вспомнить нашу старую дискуссию с Evg по этому поводу

На форуме очень много подобных полезных споров. Временами так хочется взять такую тему, выкинуть из неё весь мусор, весь срач, весь сарказм, весь спор и оставить только материал по существу. Один раз я даже попытался это сделать и вроде бы именно по той самой теме. Потратил на это много времени и понял, что получилась фигня. Просто потому, что в споре как минимум две стороны и они освещают взгляд на вопрос каждый по своему. А после выкидывания спора остаётся "как нужно делать правильно", но при этом практически полностью теряется "почему нужно делать именно так, а не эдак". В итоге больше пользы будет при чтении оригинального спора, пусть даже и читать это трудно

@Undisputed · 23.08.2017, 12:32 **[ТС]**

Убежденный,
Спасибо за совет! Ну алгоритмы и архитектура это само собой, просто хотел уточнить для себя этот момент, что бы лучше разбираться в том как это работает

Renji,
Evg,
В целом понятно, спасибо!

Ещё читал что можно перед объявлением функции в .h файле явно написать ключевое слово inline и что это поможет компилятору заинлайнить эту функцию. Но каким образом, если единица трансляции уже скомпилирована а реализация находится за её пределами?

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

И не знаешь кому верить. Наверное надо учиться понимать ассемблерные листинги, компилить, проверять на каждом компиляторе....

@Renji · 23.08.2017, 12:41

Сообщение от Undisputed

Ещё читал что можно перед объявлением функции в .h файле явно написать ключевое слово inline и что это поможет компилятору заинлайнить эту функцию. Но каким образом, если единица трансляции уже скомпилирована а реализация находится за её пределами?

Реализация может лежать в том же h файле:

C++
1
2
3
4
5
6
7
struct Test
{
    inline void inlineFunction();
};
 
//нужно если inlineFunction использует некий класс, не определенный перед Test
inline void Test::inlineFunction(){}

@Undisputed · 23.08.2017, 12:55 **[ТС]**

Renji,
Ну когда реализация находится в том же файле это вопросов не вызывает...

Croessmah · 23.08.2017, 13:59

Ещё читал что можно перед объявлением функции в .h файле явно написать ключевое слово inline и что это поможет компилятору заинлайнить эту функцию.

Без inline потом получим multiple definition
для функций с внешней линковкой.

Evg · 23.08.2017, 14:48

Сообщение от Undisputed

Ещё читал что можно перед объявлением функции в .h файле явно написать ключевое слово inline и что это поможет компилятору заинлайнить эту функцию. Но каким образом, если единица трансляции уже скомпилирована а реализация находится за её пределами?

https://www.cyberforum.ru/blogs/18334/blog93.html раздел 2.1
Правда вопрос я толком всё равно не понял

@hoggy · 23.08.2017, 15:58

Сообщение от Renji

так мертвым грузом и висит

линкер? не, не слышал.

Добавлено через 8 минут

Сообщение от Undisputed

Читал что когда включают хедер но не реализацию в единицу трансляции, это мешает компилятору инлайнить функции/методы

современному компилятору никто не мешает подглядеть
что есть в спп файлах.

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

Сообщение от Undisputed

Выходит если важна производительность, то такие хедера лучше не использовать?

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

инйлан компилятора - его епархия.
он сам знает что и когда нужно инлайнить.
вас это не касается.

@Renji · 23.08.2017, 16:34

Сообщение от hoggy

линкер? не, не слышал.

Линкер работает с объектными модулями содержащими код для всего cpp разом. Вычленять оттуда код отдельных недостижимых функций он не умеет. Если быть точным, gcc с ключом -ffunction-sections все же может генерировать "умные" объектные файлы, в которых функции не перемешались в неразделимую кашу. Но по умолчанию на это забивается.

Evg · 23.08.2017, 16:44

Сообщение от Renji

Если быть точным, gcc с ключом -ffunction-sections все же может генерировать "умные" объектные файлы, в которых функции не перемешались в неразделимую кашу

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

@hoggy · 23.08.2017, 16:50

Сообщение от Renji

Линкер работает с объектными модулями содержащими код для всего cpp разом.

для всего lib/bin
и он очень хорошо умеет вычленять весь неиспользованный стафф.

Croessmah · 23.08.2017, 16:52

Evg, strip, емнип, выпилит неиспользуемые функции.

Evg · 24.08.2017, 16:47

Сообщение от Croessmah

Evg, strip, емнип, выпилит неиспользуемые функции

Нет. strip выпиливает только "ненужные" секции. "Ненужность", думается, определяется на основании того, что секция не загружается в память в момент запуска программы (например, секции с отладочной информацией)

Новые блоги и статьи Все статьи Все блоги /
Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .	Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .
Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .	Создание Single Page Application на фреймах krapotkin 16.11.2025 Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .	Фото: Daniel Greenwood kumehtar 13.11.2025	Расскажи мне о Мире, бродяга kumehtar 12.11.2025 — Расскажи мне о Мире, бродяга, Ты же видел моря и метели. Как сменялись короны и стяги, Как эпохи стрелою летели. - Этот мир — это крылья и горы, Снег и пламя, любовь и тревоги, И бескрайние. . .

@Undisputed 901 / 478 / 93 Регистрация: 10.06.2014 Сообщений: 2,700

	Мешает ли разделение кода на объявление (.h) и определение (.cpp) inline оптимизации? 22.08.2017, 16:33. Показов 1428. Ответов 18 Метки нет (Все метки) Читал что когда включают хедер но не реализацию в единицу трансляции, это мешает компилятору инлайнить функции/методы ввиду того что нужного кода в этой единице трансляции нет, инлайнить нечего, и поэтому компилятор вынужден генерировать код который представляет собой именно вызов функции. Выходит если важна производительность, то такие хедера лучше не использовать? Насколько я понимаю использование .h файлов дают возможность ознакомиться с интерфейсом реализации в простой форме(не вникая в саму реализацию когда мы читаем код), а так же ускоряет компиляцию за счёт того что в единице трансляции отсутствует код реализации, за счёт этого конечный бинарник по идее должен быть меньше чем если бы мы включали реализацию в каждую единицу трансляции. Верны ли эти утверждения? 0

Evg 21281 / 8305 / 637 Регистрация: 30.03.2009 Сообщений: 22,660 Записей в блоге: 30
	22.08.2017, 21:04
	Ты просто смотришь на вопрос в немного вывернутой форме. При проектировании программы функции нужно распихивать по различным модулям (единицам компиляции) таким образом, чтобы горячие вызовы по возможности находились внутри одного модуля. Грамотное использование *.h упрощает этот процесс 1

@Undisputed 901 / 478 / 93 Регистрация: 10.06.2014 Сообщений: 2,700
	22.08.2017, 22:59 [ТС]
	Evg, Всмысле в один модуль? По смыслу это может быть некорректно... Может быть как модуль работающий с базой данных, а другой работает с сетью, ты предлагаешь все это оформить как один модуль? Но я так и не понял как решить проблему которая связывает руки компилятору и не позволяет ему инлайнить(если конечно это утверждение верно, и такая проблема есть. Во всяком случае читал что есть...). Первое что приходит в голову это не использовать .h 0

@Undisputed 901 / 478 / 93 Регистрация: 10.06.2014 Сообщений: 2,700
	23.08.2017, 12:32 [ТС]
	Убежденный, Спасибо за совет! Ну алгоритмы и архитектура это само собой, просто хотел уточнить для себя этот момент, что бы лучше разбираться в том как это работает Renji, Evg, В целом понятно, спасибо! Ещё читал что можно перед объявлением функции в .h файле явно написать ключевое слово inline и что это поможет компилятору заинлайнить эту функцию. Но каким образом, если единица трансляции уже скомпилирована а реализация находится за её пределами? Вот это немного путает. Где то говорят что если реализация находится в другой единице трансляции то про инлайн можно забыть, а где то говорят что в таком случае достаточно явно указать инлайн при объявлении функции. И не знаешь кому верить. Наверное надо учиться понимать ассемблерные листинги, компилить, проверять на каждом компиляторе.... 0

@Undisputed 901 / 478 / 93 Регистрация: 10.06.2014 Сообщений: 2,700
	23.08.2017, 12:55 [ТС]
	Renji, Ну когда реализация находится в том же файле это вопросов не вызывает... 0

Croessmah Неэпический 18144 / 10728 / 2066 Регистрация: 27.09.2012 Сообщений: 27,026 Записей в блоге: 1
	23.08.2017, 16:52
	Evg, `strip`, емнип, выпилит неиспользуемые функции. 0