Как правильно использовать предварительно скомпилированные заголовки в библиотеке? - PullRequest
Новая
       23

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

0 голосов
/ 25 марта 2020

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

До этого каждый проект имел stdafx.h, который содержал все необходимое для этого проекта и все используемые им общие классы. Теперь я пытаюсь создать предварительно скомпилированный заголовок для каждого пакета Conan, чтобы они собирались независимо.

Икотация имеет следующий сценарий:

ClassA.h 

//If I don't include LibraryPrecompiledHeader.h here or in example.cpp, 
//the method signature below will not compile.

class ClassA
{
public:
    HRESULT Method1(LPCTSTR str);
};

ClassA. cpp

#include "LibraryPrecompiledHeader.h"
...

LibraryPrecompiledHeader.h 

#pragma once

#include <atlstr.h>
#include <atlcoll.h>

Пример. cpp (тестовый класс Конана, использующий библиотеку) 

#include "LibraryPrecompiledHeader.h" //It will not build without including this here
                                      //or in ClassA.h
#include "ClassA.h"
...

I Можно придумать несколько способов сделать эту работу, ни один из которых мне не нравится:

  1. Включить LibraryPrecompiledHeader.h в Пример. cpp. Это означало бы, что любой потребитель библиотеки должен будет делать то же самое каждый раз, когда нужен класс из библиотеки.
  2. Включить LibraryPrecompiledHeader.h в ClassA.h. Это привело к конфликтам позже, когда проект использует несколько пакетов, каждый со своими предварительно скомпилированными заголовками. В частности, я сталкиваюсь с проблемой того, что windows .h включается несколько раз различными заголовками ATL & MF C.

Обновление: эта проблема не указана c для предварительно скомпилированных заголовков. Если я просто включу atlstr.h напрямую, я все равно должен включить его в ClassA.h или в пример. cpp. Оказывается, MF C и ATL пытаются вытянуть Windows .h. Включения MF C должны быть на первом месте, чтобы избежать двойного включения windows .h, что сложно гарантировать, если каждый пакет включает только то, что ему нужно.

Создайте One-Precompiled-Header-To-Rule-Them-All и используйте его везде. Это означает наличие огромного предварительно скомпилированного заголовка, включенного даже в самые маленькие библиотеки. Включите зависимости для библиотеки в предварительно скомпилированный заголовок класса, который в конечном итоге потребляет их. Это тесно связывает потребителя с реализацией библиотеки.

Есть что-то, чего мне не хватает?

...