Блог

Я работаю над очень маленьким фрагментом исходного кода C / C . Программа считывает входные значения из stdin, обрабатывает их с помощью алгоритма и записывает результаты в стандартный вывод.

Я бы просто реализовал все это в одном файле, но мне также нужны тестовые примеры для алгоритма (не для чтения ввода / вывода), поэтому в моем проекте есть следующие файлы:

• main.cpp
• сортировка.hpp
• sort_test.cpp

Я сразу же реализую алгоритм в sort.hpp, нет sort.cpp . Он довольно короткий и не имеет никаких зависимостей.

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

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

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

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

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

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

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

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

Можно поместить любую функцию в заголовок, если это inline . Такие вещи, как функции, определенные внутри class { } , и шаблоны неявно inline .

Если результирующее приложение становится слишком большим, оптимизируйте размер кода. Оптимизация до возникновения проблемы — это антишаблон, особенно когда есть преимущество в том, чтобы делать это «по-своему», и исправить это так же просто, как переместить из одного файла в другой и стереть inline .

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

Подавляющее большинство библиотек boost предназначены только для заголовков, поэтому я бы сказал: да, это устоявшаяся и принятая практика. Просто не забудьте inline .

Это действительно правильный выбор. Но включение этого в заголовок означает, что это будет встроенный код, а не функция. Если вам нужна такая же функциональность, вы могли бы использовать ключевое слово inline:

 inline int max(int a, int b)
{
  return (a > b) ? a : b;
}
  

http://en.wikipedia.org/wiki/Inline_function

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

Если вы хотите встроить функцию, она ДОЛЖНА быть в заголовке, иначе она не сможет быть встроена.

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

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

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

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