Почему шаблоны могут быть реализованы только в заголовочном файле?

Здесь много правильных ответов, но я хотел добавить это (для полноты):

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

Изменить: добавление примера явного создания экземпляра шаблона. Используется после определения шаблона и определены все функции-члены.

template class vector<int>;

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

Вышеприведенный пример бесполезен, поскольку вектор полностью определен в заголовках, за исключением случаев, когда общий файл include (precompiled header?) использует extern template class vector<int>, чтобы он не создавал его во всех других (1000?) файлах, которые использовать вектор.

Это из-за требования для отдельной компиляции и потому, что шаблоны являются полиморфизмом типа создания экземпляров.

Давайте немного приблизимся к конкретному для объяснения. Скажем, у меня есть следующие файлы:

• foo.h
  • объявляет интерфейс class MyClass<T>
• foo.cpp
  • определяет реализацию class MyClass<T>
• bar.cpp
  • использует MyClass<int>

Отдельная компиляция означает, что я должен скомпилировать foo.cpp независимо от bar.cpp. Компилятор полностью выполняет всю сложную работу по анализу, оптимизации и генерации кода на каждом модуле компиляции; нам не нужно анализировать целую программу. Это только компоновщик, который должен обрабатывать всю программу одновременно, и задача компоновщика значительно упрощается.

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

"Полиморфизм в стиле объектов" означает, что шаблон MyClass<T> не является общим классом, который может быть скомпилирован в код, который может работать для любого значения T. Это добавит накладные расходы, такие как бокс, необходимо передать указатели на функции для распределителей и конструкторов и т.д. Намерение шаблонов С++ состоит в том, чтобы избежать необходимости писать почти идентичные class MyClass_int, class MyClass_float и т.д., Но все равно быть в состоянии закончить с компилированным кодом, который в основном, как если бы мы писали каждую версию отдельно. Таким образом, шаблон является буквально шаблоном; шаблон класса не является классом, это рецепт создания нового класса для каждого T, с которым мы сталкиваемся. Шаблон не может быть скомпилирован в код, только результат создания экземпляра шаблона может быть скомпилирован.

Поэтому, когда компилятор foo.cpp компилируется, компилятор не может видеть bar.cpp, чтобы знать, что требуется MyClass<int>. Он может видеть шаблон MyClass<T>, но он не может испускать для него код (это шаблон, а не класс). И когда компилируется bar.cpp, компилятор может видеть, что ему нужно создать MyClass<int>, но он не может видеть шаблон MyClass<T> (только его интерфейс в foo. h), поэтому он не может его создать.

Если foo.cpp использует MyClass<int>, тогда код для него будет сгенерирован при компиляции foo.cpp, поэтому, когда bar.o связано с foo.o, они могут быть подключены и будут работать. Мы можем использовать этот факт, чтобы позволить конечный набор экземпляров шаблонов быть реализован в .cpp файле, написав один шаблон. Но нет возможности использовать bar.cpp, чтобы использовать шаблон в качестве шаблона и создавать его на всех типах, которые ему нравятся; он может использовать только ранее существовавшие версии шаблонного шаблона, о которых думал автор foo.cpp.

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

• baz.cpp
  • объявляет и реализует class BazPrivate и использует MyClass<BazPrivate>

Невозможно, чтобы это могло работать, если мы не

• При необходимости перекомпилировать foo.cpp каждый раз, когда мы меняем какой-либо другой файл в программе, в случае добавления нового нового экземпляра MyClass<T>
• Требовать, чтобы baz.cpp содержал (возможно, через заголовок) полный шаблон MyClass<T>, чтобы компилятор мог генерировать MyClass<BazPrivate> во время компиляции baz.cpp.

Никто не любит (1), потому что системы компиляции целых программ навсегда собираются для компиляции и потому что это не позволяет распространять скомпилированные библиотеки без исходного кода. Итак, у нас есть (2).

Шаблоны должны быть созданы компилятором, прежде чем компилировать их в объектный код. Это создание может быть достигнуто только в том случае, если известны аргументы шаблона. Теперь представьте сценарий, в котором функция шаблона объявлена ​​в a.h, определенном в a.cpp и используемом в b.cpp. Когда a.cpp скомпилирован, не обязательно известно, что для предстоящей компиляции b.cpp потребуется экземпляр шаблона, не говоря уже об этом конкретном экземпляре. Для большего количества заголовков и исходных файлов ситуация может быстро усложниться.

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

Фактически, до C++ 11 стандарт определял ключевое слово export, которое позволяло бы объявлять шаблоны в файле заголовка и реализовывать их в другом месте.

Ни одно из популярных компиляторов не реализовало это ключевое слово. Единственный, о котором я знаю, - это интерфейс, написанный Edison Design Group, который используется компилятором Comeau C++. Все остальные требовали, чтобы вы писали шаблоны в заголовочных файлах, потому что компилятору необходимо определение шаблона для надлежащего создания экземпляра (как уже указывали другие).

В результате стандартная комиссия ISO C++ решила удалить функцию export шаблонов с помощью C++ 11.

Хотя в стандартном С++ нет такого требования, некоторым компиляторам требуется, чтобы все шаблоны функций и классов были доступны в каждой используемой системе переводов. Фактически для этих компиляторов тела шаблонных функций должны быть доступны в файле заголовка. Повторить: это означает, что эти компиляторы не позволят их определять в файлах без заголовка, таких как .cpp файлы

Существует ключевое слово export, которое должно смягчить эту проблему, но оно нигде не является переносимым.

Шаблоны должны использоваться в заголовках, потому что компилятор должен создавать экземпляры разных версий кода в зависимости от параметров, заданных/выведенных для параметров шаблона. Помните, что шаблон не представляет собой код напрямую, а шаблон для нескольких версий этого кода. Когда вы компилируете функцию без шаблона в файле .cpp, вы компилируете конкретную функцию/класс. Это не относится к шаблонам, которые могут быть созданы с использованием разных типов, а именно, при исчислении конкретных параметров шаблона конкретный код должен быть испущен.

Была найдена функция с ключевым словом export, предназначенная для отдельной компиляции. Функция export устарела в C++11 и, AFAIK, только один компилятор реализовал ее. Вы не должны использовать export. Отдельная компиляция невозможна в C++ или C++11, но, возможно, в C++17, если понятия в нее входят, мы могли бы иметь некоторый способ отдельной компиляции.

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

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

Это означает, что наиболее переносимым способом определения реализации методов классов шаблонов является определение их внутри определения класса шаблона.

template < typename ... >
class MyClass
{

    int myMethod()
    {
       // Not just declaration. Add method implementation here
    }
};

Несмотря на то, что есть много хороших объяснений выше, я пропускаю практический способ разделения шаблонов на заголовок и тело.
Моя главная задача - избегать перекомпиляции всех пользователей шаблонов, когда я изменяю его определение.
Наличие всех экземпляров шаблонов в корпусе шаблона не является жизнеспособным решением для меня, поскольку автор шаблона может не знать всех, если его использование и пользователь шаблона могут не иметь права изменять его.
Я применил следующий подход, который работает и для старых компиляторов (gcc 4.3.4, aCC A.03.13).

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

Схематический пример:

MyTemplate.h:

#ifndef MyTemplate_h
#define MyTemplate_h 1

template <class T>
class MyTemplate
{
public:
  MyTemplate(const T& rt);
  void dump();
  T t;
};

#endif

MyTemplate.cpp:

#include "MyTemplate.h"
#include <iostream>

template <class T>
MyTemplate<T>::MyTemplate(const T& rt)
: t(rt)
{
}

template <class T>
void MyTemplate<T>::dump()
{
  cerr << t << endl;
}

MyInstantiatedTemplate.h:

#ifndef MyInstantiatedTemplate_h
#define MyInstantiatedTemplate_h 1
#include "MyTemplate.h"

typedef MyTemplate< int > MyInstantiatedTemplate;

#endif

MyInstantiatedTemplate.cpp:

#include "MyTemplate.cpp"

template class MyTemplate< int >;

main.cpp:

#include "MyInstantiatedTemplate.h"

int main()
{
  MyInstantiatedTemplate m(100);
  m.dump();
  return 0;
}

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

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

Это точно правильно, потому что компилятор должен знать, какой тип он предназначен для распределения. Поэтому классы шаблонов, функции, перечисления и т.д. Должны быть реализованы также в файле заголовка, если он должен быть опубликован или частично из библиотеки (статический или динамический), поскольку файлы заголовков НЕ скомпилированы в отличие от файлов c/cpp, которые находятся. Если компилятор не знает, что тип не может его скомпилировать. В .Net это возможно, потому что все объекты происходят из класса Object. Это не .Net.

Способ иметь отдельную реализацию выглядит следующим образом.

//inner_foo.h

template <typename T>
struct Foo
{
    void doSomething(T param);
};


//foo.tpp
#include "inner_foo.h"
template <typename T>
void Foo<T>::doSomething(T param)
{
    //implementation
}


//foo.h
#include <foo.tpp>

//main.cpp
#include <foo.h>

inner_foo имеет форвардные объявления. foo.tpp имеет реализацию и включает inner_foo.h; и foo.h будет иметь только одну строку, чтобы включить foo.tpp.

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

Я делаю это, потому что статические анализаторы для кода разбиваются, когда он не видит передовые объявления класса в *.tpp. Это раздражает при написании кода в любой среде IDE или с помощью YouCompleteMe или других.

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

myQueue.hpp:

template <class T> 
class QueueA {
    int size;
    ...
public:
    template <class T> T dequeue() {
       // implementation here
    }

    bool isEmpty();

    ...
}    

myQueue.cpp:

// implementation of regular methods goes like this:
template <class T> bool QueueA<T>::isEmpty() {
    return this->size == 0;
}


main()
{
    QueueA<char> Q;

    ...
}

Компилятор будет генерировать код для каждого экземпляра шаблона при использовании шаблона во время этапа компиляции. В процессе компиляции и компоновки файлы .cpp преобразуются в чистый объект или машинный код, который в них содержит ссылки или символы undefined, потому что файлы .h, которые включены в ваш файл main.cpp, не имеют реализации YET. Они готовы быть связаны с другим объектным файлом, который определяет реализацию для вашего шаблона, и, следовательно, у вас есть полный исполняемый файл a.out. Однако, поскольку шаблоны необходимо обработать на этапе компиляции, чтобы сгенерировать код для каждого экземпляра шаблона, который вы делаете в своей основной программе, ссылка не поможет, поскольку компиляция main.cpp в main.o, а затем компиляция вашего шаблона .cpp в template.o, а затем ссылка не будет достигать цели шаблонов, потому что я связываю различные экземпляры шаблонов с одной и той же реализацией шаблона! И шаблоны должны делать обратное, чтобы иметь одну реализацию, но допускать много доступных экземпляров с использованием одного класса.

Значение typename T будет заменено на этапе компиляции не на этапе связывания, поэтому, если я попытаюсь скомпилировать шаблон без T, который будет заменен как конкретный тип значения, поэтому он не будет работать, потому что определение шаблонов это компилировать процесс времени и мета-программирование btw - все это об использовании этого определения.

Это потому, что стандарт C++ управляется комитетом.

Более глубокая социологическая причина - некомпетентность коллективных образований признать свои ошибки.