Когда библиотеки только для заголовка приемлемы?

Over-inflining - это, вероятно, то, к чему следует обратиться вызывающему абоненту, настраивая его опции компилятора, а не вызывающему абоненту, пытающемуся управлять им с помощью очень грубых инструментов ключевого слова inline и определений в заголовках. Например, GCC имеет -finline-limit и друзей, поэтому вы можете использовать разные правила встраивания для разных единиц перевода. То, что для вас является перевыполнением, может не быть перевыполнением для меня, в зависимости от архитектуры, размера и скорости кэша инструкций, того, как используется функция и т.д. Не то, чтобы мне когда-либо приходилось делать такую настройку: на практике, когда об этом стоило беспокоиться, стоило переписывать, но это может быть совпадением. В любом случае, если я являюсь пользователем библиотеки, то при прочих равных условиях я бы предпочёл иметь возможность встраивать (с учётом моего компилятора, и который я, возможно, не возьму на себя), чем быть неспособным к встраиванию.

Я думаю, что ужас раздувания кода из заголовочных библиотек исходит больше от беспокойства о том, что компоновщик не сможет удалить лишние копии кода. Так что, независимо от того, будет ли функция на самом деле встроена на сайтах компоновщиков или нет, беспокойство заключается в том, что в конечном итоге вы получите вызываемую копию функции (или класса) для каждого объектного файла, который ее использует. Я не могу вспомнить, должны ли адреса, обращённые к встроенным функциям в разных единицах трансляции в Си++, сравниваться равными, но даже если предположить, что они равны, так что есть одна "каноническая" копия функции в связанном коде, это не обязательно означает, что компоновщик на самом деле удалит мертвые дубликаты функций. Если функция определена только в одной единице трансляции, вы можете быть достаточно уверены, что на каждую статическую библиотеку или исполняемый файл, использующий ее, будет только одна отдельная копия.

Честно говоря, я не знаю, насколько обоснован этот страх. Всё, над чем я работал, либо было настолько сильно ограничено в памяти, что мы использовали inline только как функции static inline настолько маленькие, что мы не ожидаем, что inlined-версия будет заметно больше, чем код для вызова, и не возражаем против дубликатов, либо настолько слабо ограничены, что нас не волнуют никакие дубликаты нигде. Я еще никогда не попадал на середину пути поиска и подсчета дубликатов на разных компиляторах. Иногда я слышал от других, что это проблема с кодом шаблонов, так что я верю, что в утверждениях есть правда.

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

// declare.h
inline int myfunc(int);

class myclass {
    inline int mymemberfunc(int);
};

// define.h
#include "declare.h"
int myfunc(int a) { return a; }

int myclass::mymemberfunc(int a) { return myfunc(a); }

Вызовы, которые беспокоятся о раздутом коде, вероятно, могут перехитрить свой компилятор, включив declare.h во все свои файлы, а затем написав:

// define.cpp
#include "define.h"

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

Абоненты, которые не беспокоятся о раздувании кода, могут использовать файл define.h во всех своих файлах.

По моему опыту, раздувание не было проблемой:

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

• У компиляторов обычно есть параметры для оптимизации, чтобы контролировать объем встраивания; / Os на компиляторах Microsoft.

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

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

Согласен, встроенные библиотеки намного проще использовать.

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

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

Второй проблемой может быть время компиляции, даже при использовании прекомпилированного заголовка (тоже есть компромиссы).

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

Я увидел следующий механизм, дающий пользователю возможность выбора:

// foo.h
#ifdef MYLIB_USE_INLINE_HEADER
#define MYLIB_INLINE inline
#else 
#define MYLIB_INLINE 
#endif

void Foo();  // a gazillion of declarations

#ifdef MYLIB_USE_INLINE_HEADER
#include "foo.cpp"
#endif

// foo.cpp
#include "foo.h"
MYLIB_INLINE void Foo() { ... }