Przechowywanie definicji funkcji szablonu C ++ w pliku .CPP

Mam kod szablonu, który wolałbym przechowywać w pliku CPP zamiast wbudowanego w nagłówku. Wiem, że można to zrobić, o ile wiesz, jakie typy szablonów będą używane. Na przykład:

plik .h

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

plik .cpp

template <typename T>
void foo::do(const T& t)
{
    // Do something with t
}

template void foo::do<int>(const int&);
template void foo::do<std::string>(const std::string&);

Zwróć uwagę na ostatnie dwa wiersze - funkcja szablonu foo :: do jest używana tylko z ints i std :: strings, więc te definicje oznaczają, że aplikacja się połączy.

Moje pytanie brzmi - czy to paskudny hack, czy będzie to działać z innymi kompilatorami / linkerami? Obecnie używam tego kodu tylko z VS2008, ale będę chciał przenieść się do innych środowisk.

Opisany problem można rozwiązać, definiując szablon w nagłówku lub stosując podejście opisane powyżej.

Polecam przeczytanie następujących punktów z C ++ FAQ Lite :

• Dlaczego nie mogę oddzielić definicji mojej klasy szablonów od jej deklaracji i umieścić jej w pliku .cpp?
• Jak mogę uniknąć błędów linkera w moich funkcjach szablonu?
• W jaki sposób eksport słowa kluczowego C ++ pomaga w przypadku błędów linkera szablonów?

Zagłębiają się w wiele szczegółów na temat tych (i innych) problemów z szablonami.

Dla innych na tej stronie, którzy zastanawiają się, jaka jest poprawna składnia (podobnie jak ja) w przypadku jawnej specjalizacji szablonów (lub przynajmniej w VS2008), jej następująca ...

W twoim pliku .h ...

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

I w twoim pliku .cpp

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

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

Ten kod jest dobrze sformułowany. Trzeba tylko zwrócić uwagę, że definicja szablonu jest widoczna w momencie tworzenia wystąpienia. Cytując standard, § 14.7.2.4:

Definicja nieeksportowanego szablonu funkcji, nieeksportowanego szablonu funkcji składowej lub nieeksportowanej funkcji składowej lub elementu danych statycznych szablonu klasy musi być obecna w każdej jednostce tłumaczeniowej, w której jest wyraźnie utworzona.

Powinno to działać dobrze wszędzie tam, gdzie obsługiwane są szablony. Jawna instancja szablonu jest częścią standardu C ++.

Twój przykład jest poprawny, ale niezbyt przenośny. Istnieje również nieco czystsza składnia, której można użyć (jak wskazał @ namespace-sid).

Załóżmy, że klasa szablonowa jest częścią biblioteki, która ma być udostępniana. Czy należy kompilować inne wersje klasy szablonowej? Czy opiekun biblioteki powinien przewidywać wszystkie możliwe zastosowania klasy w szablonie?

Alternatywne podejście to niewielka odmiana tego, co masz: dodaj trzeci plik, który jest plikiem implementacji / tworzenia szablonu.

plik foo.h

// Standard header file guards omitted

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

plik foo.cpp

// Always include your headers
#include "foo.h"

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

plik foo-impl.cpp

// Yes, we include the .cpp file
#include "foo.cpp"
template class foo<int>;

Jedynym zastrzeżeniem jest to, że musisz powiedzieć kompilatorowi, aby skompilował, foo-impl.cppzamiast foo.cppkompilowania tego drugiego.

Oczywiście możesz mieć wiele implementacji w trzecim pliku lub mieć wiele plików implementacji dla każdego typu, którego chcesz użyć.

Umożliwia to znacznie większą elastyczność podczas udostępniania klasy wzorcowej do innych zastosowań.

Ta konfiguracja skraca również czas kompilacji ponownie używanych klas, ponieważ nie rekompilujesz tego samego pliku nagłówka w każdej jednostce tłumaczeniowej.

To zdecydowanie nie jest nieprzyjemny hack, ale pamiętaj, że będziesz musiał to zrobić (wyraźna specjalizacja szablonu) dla każdej klasy / typu, którego chcesz użyć z danym szablonem. W przypadku WIELU typów żądających utworzenia szablonu może być WIELE plików w pliku .cpp. Aby rozwiązać ten problem, możesz mieć TemplateClassInst.cpp w każdym używanym projekcie, aby mieć większą kontrolę nad typami, które będą tworzone. Oczywiście to rozwiązanie nie będzie idealne (inaczej srebrna kula), ponieważ może to doprowadzić do złamania ODR :).

W najnowszym standardzie istnieje słowo kluczowe ( export), które pomogłoby złagodzić ten problem, ale nie jest ono zaimplementowane w żadnym znanym mi kompilatorze innym niż Comeau.

Zobacz najczęściej zadawane pytania na ten temat.

Jest to standardowy sposób definiowania funkcji szablonów. Sądzę, że czytam trzy metody definiowania szablonów. Lub prawdopodobnie 4. Każdy z zalet i wad.

1. Zdefiniuj w definicji klasy. W ogóle mi się to nie podoba, ponieważ uważam, że definicje klas mają charakter wyłącznie informacyjny i powinny być łatwe do odczytania. Jednak znacznie trudniej jest zdefiniować szablony w klasie niż na zewnątrz. I nie wszystkie deklaracje szablonów są na tym samym poziomie złożoności. Ta metoda sprawia również, że szablon jest prawdziwym szablonem.

2. Zdefiniuj szablon w tym samym nagłówku, ale poza klasą. Jest to mój preferowany sposób przez większość czasu. Utrzymuje porządek w definicji klasy, szablon pozostaje prawdziwym szablonem. Wymaga to jednak pełnego nazewnictwa szablonów, co może być trudne. Ponadto twój kod jest dostępny dla wszystkich. Ale jeśli potrzebujesz wbudowanego kodu, jest to jedyny sposób. Możesz to również osiągnąć, tworząc plik .INL na końcu definicji klas.

3. Uwzględnij nagłówek.h oraz implementację.CPP w pliku main.CPP. Myślę, że tak to się robi. Nie będziesz musiał przygotowywać żadnych wcześniejszych instancji, zachowa się jak prawdziwy szablon. Problem, który mam z tym, to, że nie jest to naturalne. Zwykle nie dołączamy plików źródłowych i nie oczekujemy ich. Sądzę, że odkąd załączyłeś plik źródłowy, funkcje szablonu można wstawiać.

4. Ta ostatnia metoda, która była opublikowana, polega na definiowaniu szablonów w pliku źródłowym, podobnie jak numer 3; ale zamiast dołączać plik źródłowy, tworzymy szablony według potrzebnych nam szablonów. Nie mam problemu z tą metodą i czasem się przydaje. Mamy jeden duży kod, nie można czerpać korzyści z wstawiania go, więc po prostu umieść go w pliku CPP. A jeśli znamy typowe instancje i możemy je wstępnie zdefiniować. To oszczędza nam pisania w zasadzie 5, 10 razy tego samego. Ta metoda ma tę zaletę, że nasz kod jest zastrzeżony. Ale nie polecam umieszczania małych, regularnie używanych funkcji w plikach CPP. Zmniejszy to wydajność Twojej biblioteki.

Uwaga: nie jestem świadomy konsekwencji rozdętego pliku obj.

Tak, to standardowy sposób specjalizacji jawnej instancji . Jak już wspomniano, nie można utworzyć tego szablonu z innymi typami.

Edycja: poprawione na podstawie komentarza.

Weźmy jeden przykład, powiedzmy z jakiegoś powodu, że chcesz mieć klasę szablonów:

//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");
}

Jeśli skompilujesz ten kod za pomocą Visual Studio - działa on od razu po rozpakowaniu. gcc wyświetli błąd linkera (jeśli ten sam plik nagłówkowy jest używany z wielu plików .cpp):

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

Możliwe jest przeniesienie implementacji do pliku .cpp, ale wtedy musisz zadeklarować klasę w ten sposób -

//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>;

A potem .cpp będzie wyglądać tak:

//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");
}

Bez dwóch ostatnich wierszy w pliku nagłówkowym - gcc będzie działało dobrze, ale Visual Studio wyświetli błąd:

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

składnia klasy szablonów jest opcjonalna, jeśli chcesz udostępnić funkcję poprzez eksport .dll, ale dotyczy to tylko platformy Windows - test_template.h mógłby wyglądać następująco:

//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();

z plikiem .cpp z poprzedniego przykładu.

To jednak powoduje więcej bólu głowy dla linkera, więc zaleca się użycie poprzedniego przykładu, jeśli nie eksportujesz funkcji .dll.

Czas na aktualizację! Utwórz plik wbudowany (.inl lub prawdopodobnie dowolny inny) i po prostu skopiuj w nim wszystkie swoje definicje. Pamiętaj, aby dodać szablon nad każdą funkcją ( template <typename T, ...>). Teraz zamiast dołączać plik nagłówkowy do pliku wbudowanego, robi się odwrotnie. Dołącz plik śródliniowy po deklaracji swojej klasy ( #include "file.inl").

Naprawdę nie wiem, dlaczego nikt o tym nie wspominał. Nie widzę żadnych bezpośrednich wad.

W podanym przykładzie nie ma nic złego. Ale muszę powiedzieć, że uważam, że przechowywanie definicji funkcji w pliku CPP nie jest efektywne. Rozumiem tylko potrzebę oddzielenia deklaracji i definicji funkcji.

W połączeniu z jawnym tworzeniem instancji klasy biblioteka sprawdzania koncepcji doładowania (BCCL) może pomóc w generowaniu kodu funkcji szablonu w plikach CPP.

Żadne z powyższych nie działało dla mnie, więc oto jak to rozwiązałeś, moja klasa ma tylko 1 szablon.

.h

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);
}

pozwala to uniknąć błędów linkera i nie trzeba w ogóle wywoływać funkcji tymczasowej