Я знаю, что это старый поток, но никто не упомянул интерфейсы ABI или конкретные проблемы компилятора. Так что я думал, что буду.
Это в основном основано на концепции, что вы либо пишете библиотеку с заголовком для распространения среди людей, либо повторно используете себя, а не все в заголовке. Если вы думаете о повторном использовании заголовочных и исходных файлов и их повторной компиляции в каждом проекте, тогда это действительно не применимо.
В основном, если вы компилируете свой код C ++ и создаете библиотеку с одним компилятором, тогда пользователь пытается использовать эту библиотеку с другим компилятором или другой версией того же компилятора, тогда вы можете получить ошибки компоновщика или странное поведение во время выполнения из-за двоичной несовместимости.
Например, поставщики компиляторов часто меняют свою реализацию STL между версиями. Если у вас есть функция в библиотеке, которая принимает std :: vector, тогда она ожидает, что байты в этом классе будут упорядочены так, как они были расположены при компиляции библиотеки. Если в новой версии компилятора поставщик улучшил эффективность std :: vector, тогда код пользователя видит новый класс, который может иметь другую структуру, и передает эту новую структуру в вашу библиотеку. Дальше все идет под откос ... Вот почему не рекомендуется передавать объекты STL через границы библиотеки. То же самое относится к типам C Run-Time (CRT).
Говоря об CRT, ваша библиотека и исходный код пользователя обычно должны быть связаны с одной и той же CRT. В Visual Studio, если вы создаете свою библиотеку с использованием многопоточной CRT, но пользователь ссылается на многопоточную отладочную CRT, у вас возникнут проблемы со связью, потому что ваша библиотека может не найти нужные символы. Я не могу вспомнить, какая это была функция, но для Visual Studio 2015 Microsoft сделала одну функцию CRT встроенной. Внезапно в заголовке оказалась не библиотека CRT, поэтому библиотеки, которые ожидали найти ее во время компоновки, больше не могли этого делать, и это приводило к ошибкам связи. В результате эти библиотеки потребовали перекомпиляции с Visual Studio 2015.
Вы также можете получить ошибки ссылок или странное поведение, если вы используете Windows API, но при сборке с другими настройками Unicode для пользователя библиотеки. Это связано с тем, что Windows API имеет функции, которые используют строки Unicode или ASCII и макросы / определяют, которые автоматически используют правильные типы на основе настроек Unicode проекта. Если вы передадите строку через границу библиотеки неправильного типа, во время выполнения все сломается. Или вы можете обнаружить, что программа вообще не ссылается.
Это также верно для передачи объектов / типов через границы библиотеки из других сторонних библиотек (например, собственный вектор или матрица GSL). Если сторонняя библиотека изменит свой заголовок между компиляцией вашей библиотеки и вашим пользователем, компилирующим свой код, все сломается.
По сути, в целях безопасности единственное, что вы можете передать через границы библиотеки, - это типы и простые старые данные (POD). В идеале любой POD должен быть в структурах, которые определены в ваших собственных заголовках и не зависят от сторонних заголовков.
Если вы предоставляете библиотеку только для заголовков, тогда весь код компилируется с одинаковыми настройками компилятора и с одними и теми же заголовками, поэтому многие из этих проблем исчезнут (если версия сторонних частично библиотек, которые вы и ваш пользователь используете, совместимы с API).
Однако есть недостатки, упомянутые выше, такие как увеличенное время компиляции. Кроме того, у вас может быть бизнес, поэтому вы не можете передавать все детали реализации исходного кода всем своим пользователям на случай, если один из них украдет их.