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

Обновлено: исправлено на основе комментария.

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

Я рекомендую прочитать следующие пункты из C++ FAQ Lite:

• Почему я не могу отделить определение моего класса шаблонов от его объявления и поместить его в файл .cpp?
• Как я могу избежать ошибок компоновщика с моими функциями шаблона?
• Как экспорт ключевых слов C++ помогает при ошибках компоновщика шаблонов?

Они подробно рассказывают об этих (и других) проблемах с шаблоном.

Это должно работать нормально везде, где поддерживаются шаблоны. Явное создание шаблона является частью стандарта C++.

В последнем стандарте есть ключевое слово (export), которое помогло бы решить эту проблему, но оно не реализовано ни в одном известном мне компиляторе, кроме Comeau.

См. FAQ-lite об этом.

Этот код хорошо сформирован. Вам нужно только обратить внимание на то, что определение шаблона видно в момент создания экземпляра. Процитируем стандарт, § 14.7.2.4:

The definition of a non-exported function template, a non-exported member function template, or a non-exported member function or static data member of a class template shall be present in every translation unit in which it is explicitly instantiated.

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

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

Это определенно не неприятный прием, но имейте в виду, что вам придется делать это (явная специализация шаблона) для каждого класса / типа, который вы хотите использовать с данным шаблоном. В случае МНОГИХ типов, запрашивающих создание шаблона, в вашем .cpp файле может быть МНОГО строк. Чтобы решить эту проблему, вы можете иметь TemplateClassInst.cpp в каждом используемом вами проекте, чтобы иметь больший контроль над тем, какие типы будут созданы. Очевидно, что это решение не будет идеальным (он же серебряная пуля), так как вы можете нарушить ODR :).

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

В вашем .h файле ...

template<typename T>
class foo
{
public:
    void bar(const T &t);
};

И в вашем файле .cpp

template <class T>
void foo<T>::bar(const T &t)
{ }

// Explicit template instantiation
template class foo<int>;

Пришло время обновления! Создайте встроенный (.inl или, возможно, любой другой) файл и просто скопируйте в него все свои определения. Не забудьте добавить шаблон над каждой функцией (template <typename T, ...>). Теперь вместо включения файла заголовка во встроенный файл вы делаете обратное. Включите встроенный файл после в объявление вашего класса (#include "file.inl").

Я действительно не знаю, почему никто не упомянул об этом. Сразу недостатков не вижу.

Ваш пример правильный, но не очень переносимый. Существует также немного более чистый синтаксис, который можно использовать (как указано, среди прочего, @ namespace-sid).

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

Следует ли компилировать другие версии шаблонного класса?

Должен ли сопровождающий библиотеки предвидеть все возможные варианты использования этого класса по шаблону?

Альтернативный подход

Добавьте третий файл, который является файлом реализации / создания шаблона в ваших источниках.

lib/foo.hppв / из библиотеки

#pragma once

template <typename T>
class foo
{
public:
    void bar(const T&);
};

lib/foo.cppкомпиляция этого файла напрямую просто тратит время компиляции

// Include guard here, just in case
#pragma once

#include "foo.hpp"

template <typename T>
void foo::bar(const T& arg)
{
    // Do something with `arg`
}

foo.MyType.cppс использованием библиотеки, явное создание экземпляра шаблона foo<MyType>

// Consider adding "anti-guard" to make sure it's not included in other translation units
#if __INCLUDE_LEVEL__ != 0
  #error "Don't include this file"
#endif

// Yes, we include the .cpp file
#include <lib/foo.cpp>
#include "MyType.hpp"

template class foo<MyType>;

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

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

Примеры использования

foo.declarations.hppнеобходимо знать об общедоступном интерфейсе foo<MyType>, но не об источниках .cpp

#pragma once

#include <lib/foo.hpp>
#include "MyType.hpp"

// Declare `temp`. Doesn't need to include `foo.cpp`
extern foo<MyType> temp;

examples.cppможет ссылаться на локальную декларацию, но также не перекомпилирует foo<MyType>

#include "foo.declarations.hpp"

MyType instance;

// Define `temp`. Doesn't need to include `foo.cpp`
foo<MyType> temp;

void example_1() {
    // Use `temp`
    temp.bar(instance);
}

void example_2() {
    // Function local instance
    foo<MyType> temp2;

    // Use templated library function
    temp2.bar(instance);
}

error.cppпример, который будет работать с чистыми шаблонами заголовков, но не здесь

#include <lib/foo.hpp>

// Causes compilation errors at link time since we never had the explicit instantiation:
// template class foo<int>;
// GCC linker gives an error: "undefined reference to `foo<int>::bar()'"

void linkerError()
{
    foo<int> nonExplicitlyInstantiatedTemplate;
}

Обратите внимание, что большинство компиляторов / линтеров / помощников по коду не распознают это как ошибку, поскольку в соответствии со стандартом C++ ошибки нет. Но когда вы собираетесь связать эту единицу трансляции с полным исполняемым файлом, компоновщик не найдет определенную версию foo<int>.

Это стандартный способ определения функций шаблона. Я думаю, что есть три метода определения шаблонов, которые я прочитал. А может, 4. У каждого свои плюсы и минусы.

1. Определите в определении класса. Мне это совсем не нравится, потому что я думаю, что определения классов предназначены исключительно для справки и должны быть легко читаемыми. Однако определить шаблоны в классе гораздо проще, чем вне его. И не все объявления шаблонов имеют одинаковый уровень сложности. Этот метод также делает шаблон настоящим шаблоном.

2. Определите шаблон в том же заголовке, но вне класса. В большинстве случаев это мой предпочтительный способ. Это сохраняет ваше определение класса аккуратным, шаблон остается истинным шаблоном. Однако для этого требуется полное именование шаблона, что может быть непросто. Также ваш код доступен всем. Но если вам нужно, чтобы ваш код был встроенным, это единственный способ. Этого также можно добиться, создав файл .INL в конце определений классов.

3. Включите header.h и implementation.CPP в свой main.CPP. Думаю, вот как это делается. Вам не нужно будет готовить какие-либо предварительные экземпляры, он будет вести себя как настоящий шаблон. Проблема в том, что это неестественно. Обычно мы не включаем и не ожидаем включения исходных файлов. Я думаю, что, поскольку вы включили исходный файл, функции шаблона могут быть встроены.

4. Этот последний метод, который был опубликован, определяет шаблоны в исходном файле, как и номер 3; но вместо включения исходного файла мы предварительно создаем экземпляры шаблонов, которые нам понадобятся. У меня нет проблем с этим методом, и он иногда бывает полезен. У нас есть один большой код, он не может выиграть от встраивания, поэтому просто поместите его в файл CPP. И если мы знаем общие экземпляры и можем их предопределить. Это избавляет нас от необходимости писать одно и то же 5-10 раз. Преимущество этого метода заключается в том, что наш код остается закрытым. Но я не рекомендую помещать крошечные, регулярно используемые функции в файлы CPP. Поскольку это снизит производительность вашей библиотеки.

Обратите внимание, я не знаю о последствиях раздутого файла obj.

Возьмем один пример, допустим, по какой-то причине вы хотите иметь шаблонный класс:

//test_template.h:
#pragma once
#include <cstdio>

template <class T>
class DemoT
{
public:
    void test()
    {
        printf("ok\n");
    }
};

template <>
void DemoT<int>::test()
{
    printf("int test (int)\n");
}


template <>
void DemoT<bool>::test()
{
    printf("int test (bool)\n");
}

Если скомпилировать этот код с помощью Visual Studio - он работает из коробки. gcc выдаст ошибку компоновщика (если один и тот же файл заголовка используется из нескольких файлов .cpp):

error : multiple definition of `DemoT<int>::test()'; your.o: .../test_template.h:16: first defined here

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

//test_template.h:
#pragma once
#include <cstdio>

template <class T>
class DemoT
{
public:
    void test()
    {
        printf("ok\n");
    }
};

template <>
void DemoT<int>::test();

template <>
void DemoT<bool>::test();

// Instantiate parametrized template classes, implementation resides on .cpp side.
template class DemoT<bool>;
template class DemoT<int>;

И тогда .cpp будет выглядеть так:

//test_template.cpp:
#include "test_template.h"

template <>
void DemoT<int>::test()
{
    printf("int test (int)\n");
}


template <>
void DemoT<bool>::test()
{
    printf("int test (bool)\n");
}

Без двух последних строк в файле заголовка - gcc будет работать нормально, но Visual Studio выдаст ошибку:

 error LNK2019: unresolved external symbol "public: void __cdecl DemoT<int>::test(void)" (?test@?$DemoT@H@@QEAAXXZ) referenced in function

Синтаксис класса шаблона является необязательным, если вы хотите предоставить функцию через экспорт .dll, но это применимо только для платформы Windows, поэтому test_template.h может выглядеть так:

//test_template.h:
#pragma once
#include <cstdio>

template <class T>
class DemoT
{
public:
    void test()
    {
        printf("ok\n");
    }
};

#ifdef _WIN32
    #define DLL_EXPORT __declspec(dllexport) 
#else
    #define DLL_EXPORT
#endif

template <>
void DLL_EXPORT DemoT<int>::test();

template <>
void DLL_EXPORT DemoT<bool>::test();

с файлом .cpp из предыдущего примера.

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

Ничего из вышеперечисленного у меня не сработало, поэтому вот как я это решил, в моем классе есть только один шаблонный метод.

.час

class Model
{
    template <class T>
    void build(T* b, uint32_t number);
};

.cpp

#include "Model.h"
template <class T>
void Model::build(T* b, uint32_t number)
{
    //implementation
}

void TemporaryFunction()
{
    Model m;
    m.build<B1>(new B1(),1);
    m.build<B2>(new B2(), 1);
    m.build<B3>(new B3(), 1);
}

это позволяет избежать ошибок компоновщика и вообще не вызывать TemporaryFunction