реализация класса в .h файле хорошо или плохо?

все знакомые мне ide разделяют класс на два файла: .h с описанием и .cpp с кодом, но, например, в boost .hpp файлы почти всегда содержат и реализацию классов, т.е. так тоже можно. так в чем тогда разница и когда какой способ нужно применять? заранее благодарен

0

Сообщение от Убежденный 1) Реализация методов в хидере. Время: 1 минута 3 секунды. ... 3) Реализация методов в отдельном файле + опция LTCG. Время: 25 секунд.

Такие результаты всё-таки говорят о том, что в режиме LTCG они всё-таки имеют какие-то дополнительные настройки компилятора. В таком тесте (когда он сформирован в виде одного исходника) никакие межмодульные оптимизации не в состоянии ускорить в 2 раза. Более, чем уверен, что в режиме без LTCG для первого теста можно добавить пару опций (понять бы только, каких), которые дадут то же самое ускорение.

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

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

gcc на втором примере в режиме -flto показал в точечности такое же время, как в первом режиме без -flto. Т.е. у gcc опция работает более честно, чем у интеловского компилятора. Т.е. опция только задаёт режим работы, не включая никаких дополнительных оптимизаций

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

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

Результаты на -flto на втором примере говорят о том, что такое предположение неверно. Скорее всего, работает некая гибридная схема. Формируем полный код а рядом кладём промежуточное представление (во всяком случае в бинарнике есть и то, и другое). Далее на финальной стадии анализируем промежуточное представление. Если ничего интересного в плане инлайна не нашли, то оставляем код, если нашли, то выполняем инлайн и перекомпиляцию. Такой подход выглядит вполне разумно, если оно именно так и реализовано, то беру назад свои слова про то, что этот режим плохой.

Но в любом случае, рекомендация по написанию методов в хидере остаётся в силе

0

В тот раз хотел сказать, но потом вылетело из головы

Сообщение от Убежденный Подтверждая, что компилятору без разницы, где находится определение - в заголовке или в файле реализации

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

Если из файла t2.cc мы сформируем динамическую библиотеку (а это один из наиболее распространённых вариантов распространения кода), то в gcc режим -flto пролетает, т.к. в динамической линковке он уже не может участвовать. Думается, на интеловском компиляторе то же самое

0