Я знаю, що це стара тема, але ніхто не згадував про інтерфейси ABI чи конкретні проблеми компілятора. Тож я думав, що буду.
В основі цього лежить концепція того, що ви або пишете бібліотеку із заголовком для розповсюдження людям, або повторно використовуєте себе проти того, щоб мати все в заголовку. Якщо ви думаєте повторно використовувати заголовок та вихідні файли та перекомпілювати їх у кожному проекті, це насправді не стосується.
В основному, якщо ви компілюєте свій код C ++ і створюєте бібліотеку з одним компілятором, тоді користувач намагається використовувати цю бібліотеку з іншим компілятором або іншою версією того самого компілятора, тоді ви можете отримати помилки компонувальника або дивну поведінку під час виконання через бінарну несумісність.
Наприклад, постачальники компіляторів часто змінюють реалізацію STL між версіями. Якщо у вас є функція в бібліотеці, яка приймає std :: vector, то вона очікує, що байти в цьому класі будуть розташовані так, як вони були розташовані під час компіляції бібліотеки. Якщо в новій версії компілятора постачальник покращив ефективність std :: vector, тоді код користувача бачить новий клас, який може мати іншу структуру, і передає цю нову структуру у вашу бібліотеку. Звідти все йде вниз ... Ось чому рекомендується не передавати об’єкти STL через межі бібліотеки. Те саме стосується типів часу виконання C (CRT).
Розмовляючи про ЕПТ, ваша бібліотека та вихідний код користувача, як правило, повинні бути пов'язані з однією і тією ж ЕПТ. З Visual Studio, якщо ви створюєте свою бібліотеку за допомогою багатопотокової ЕПТ, але користувач посилається на багатопотокову налагоджувальну ЕПТ, у вас виникнуть проблеми із посиланнями, оскільки ваша бібліотека може не знайти потрібні символи. Я не пам’ятаю, яка це була функція, але для Visual Studio 2015 Microsoft зробила одну функцію ЕПТ вбудованою. Раптом це було в заголовку, а не в бібліотеці ЕПТ, тому бібліотеки, які очікували знайти його під час зв’язку, більше не могли робити, і це спричинило помилки при зв’язку. Результатом стало те, що ці бібліотеки потребували перекомпіляції з Visual Studio 2015.
Ви також можете отримати помилки посилання або дивну поведінку, якщо ви використовуєте Windows API, але будуєте з різними налаштуваннями Unicode для користувача бібліотеки. Це пояснюється тим, що API Windows має функції, які використовують або рядки Unicode, або ASCII, і макроси / визначає, які автоматично використовують правильні типи на основі параметрів Unicode проекту. Якщо ви передаете рядок через межі бібліотеки неправильного типу, то речі порушуються під час виконання. Або ви можете виявити, що програма не пов’язує спочатку.
Це також стосується передачі об’єктів / типів через межі бібліотек від інших сторонніх бібліотек (наприклад, власний вектор або матриця GSL). Якщо стороння бібліотека змінить заголовок між компіляцією бібліотеки та користувачем, який компілює код, тоді все буде зламано.
В основному для безпеки єдині речі, які ви можете передати через межі бібліотеки, вбудовані в типи та звичайні старі дані (POD). В ідеалі будь-який POD повинен мати структури, визначені у ваших власних заголовках, і не покладатися на жодні сторонні заголовки.
Якщо ви надаєте бібліотеку лише для заголовків, тоді весь код компілюється з однаковими налаштуваннями компілятора та проти тих самих заголовків, тому багато цих проблем зникає (надання версії третіх частково бібліотек, які ви та ваш користувач використовуєте, сумісні з API).
Однак є негативи, які були згадані вище, такі як збільшений час складання. Крім того, ви можете керувати бізнесом, тож ви можете не захотіти передавати всі деталі реалізації вихідного коду всім своїм користувачам на випадок, якщо хтось із них викраде його.