2013-07-17 3 views
8

Я только что отметил this item в Google C++ Coding Style Guide - и я не совсем понял.Когда следует использовать файлы -inl.h?

Если я поместил встроенный метод или функцию в файл, отличный от заголовка, включенного другими файлами, это не будет метод класса; и он будет использоваться только для битов кода, которые включают его. Так почему же вообще есть такие -inl.h файлы?

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

+0

«long», вероятно, относительный, и в этом случае я бы предположил, что google считает что-то большее, чем одна строка – PlasmaHH

ответ

7

Это часто делается для шаблонов длинных функций. Обычный заголовок my_functions.h содержит только декларации, а файл реализации my_functions-inl.h содержит реализации. Причина в том, что шаблоны функций cannot be put in .cpp файлов. Обратите внимание: файл X.h содержит файл X-inl.h, а не наоборот.

Другие библиотеки имеют различные соглашения об именах: например. некоторые из библиотек Boost используют .hpp для заголовков шаблонов и .ipp для файлов реализации шаблона.

11

Я только что отметил этот пункт в Руководстве по стилю кодирования Google C++ - и я не совсем понял его.

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

Итак, у вас даже есть такие файлы -inl.h?

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

Кроме того, почему мы вообще хотим встроить длинные функции в любом случае?

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

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

Смежные вопросы