C ++: Когда допустимо иметь код в заголовочном файле? - PullRequest
9 голосов
/ 20 мая 2009

Меня учили хранить определения классов и код отдельно.

Тем не менее, я видел ситуации, когда люди часто включали в заголовок некоторые фрагменты кода, например простые методы доступа, которые возвращают ссылку на переменную.

Где вы рисуете линию?

Ответы [ 9 ]

15 голосов
/ 20 мая 2009

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

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

5 голосов
/ 20 мая 2009

При разработке большого проекта C ++ вам нужно быть бдительным, чтобы каждая пара файлов .CPP имела как можно меньше заголовочных файлов.

Итак, у меня есть простое правило для «рисования линии»:

Если, вставляя реализацию, ваш файл заголовка теперь должен включать дополнительный файл заголовка, вы должны переместить реализацию из заголовка в файл .CPP.

Конечно, это не единственная причина не встраивать, но это определенный пример линии, которую не следует пересекать.

5 голосов
/ 20 мая 2009

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

Иногда наличие кода только в заголовках делается намеренно, чтобы раскрыть код - ATL делает это для eaxmple.

4 голосов
/ 20 мая 2009
  1. Встроенные функции
  2. Методы с одной / двумя строками
  3. Шаблоны

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

1 голос
/ 20 мая 2009

Вам понадобится код в заголовке, если вы хотите «встроить» код. В противном случае есть больше преимуществ для прикрепления реализации в теле.

1 голос
/ 20 мая 2009

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

1 голос
/ 20 мая 2009

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

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

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

Ура!

1 голос
/ 20 мая 2009

Я бы придерживался кода в файлах .c и .cpp, а заголовки - в файлах .h, .hpp. Причина в том, что когда я загружаю исходный код в формате .tar.gz или zip, я всегда ищу файлы .h для содержимого заголовков и файлы .cpp для исходного кода. Многие привыкли к этому, поэтому я думаю, что вы должны придерживаться этого стиля.

0 голосов
/ 20 мая 2009

Это зависит от вас. Boost помещает почти весь код в заголовок ... и это уважаемая библиотека.

...