Co to jest niezawodna metoda specjalizacji szablonów w C++ dla oddzielnego nagłówka/źródła

Question

W projektach średniej wielkości lub nawet dużych złożone oddzielanie deklaracji i definicji szablonu jest przydatne w celu skrócenia czasu kompilacji.

Jednak w złożonym kodzie błędy małego programisty mogą prowadzić do niezauważonej zmiany zachowania, np. np. zamiast specjalizacji wywoływana jest wersja ogólna.

Przykład: Specjalizacja szablonów stała się niewidoczna z powodu nieodebranego zgłoszenia.

///////////////////// file A.hpp ///////////////////// 

#include <iostream> 

template <typename T> 

class A 
{ 
public: 
    void foo() 
    { 
     std::cerr << " calling generic foo " << std::endl ; 
    } 
}; 

// forgetting following declaration leads to an unintended program behaviour 
template <> void A<int>::foo(); 

///////////////////// file A-foo-int.cpp ///////////////////// 
#include "A.hpp" 

template <> 
void A<int>::foo() 
{ 
    std::cerr << "calling <int> version of foo" << std::endl; 
} 

///////////////////// file main.cpp ///////////////////// 
#include "A.hpp" 

int main(int argc , char** argv) 
{ 
    A<int>* a = new A<int>(); 
    a->foo(); 
    return 0; 
} 

///////////////////// Makefile ///////////////////// 
CC = g++ 
CPPFLAGS += -Wall -O3 
CXXFLAGS += --std=gnu++0x 

all: nonrobust-template-setup 

nonrobust-template-setup: main.o A-foo-int.o 
    $(CC) $(CPPFLAGS) main.o A-foo-int.o -o nonrobust-template-setup 

clean: 
    rm -rf *.o nonrobust-template-setup 

////////////////////////////////////////// 

Pytanie: jest bardziej wytrzymała konfiguracji możliwe (compiler- i niezależny od platformy) i jeśli, jak to będzie wyglądać?

Jeśli nie, jaki jest dobry sposób na sprawdzenie, czy wybrana jest pożądana wersja funkcji?

Answer 1

Nie można oddzielne deklaracje i definicje w ten sposób: jeśli spycha definicję swoich wyspecjalizowanych funkcji składowych w oddzielnym .cpp pliku, bez względu na to, czy zadeklarować swoją specjalizację natychmiast po pierwszym szablonie, kompilator nie będzie mógł stwórz go, a linker będzie narzekał na nierozwiązane referencje.

Normalnie, definicja funkcji członek szablonu klasy idzie w pliku nagłówkowym, chyba podać jednoznaczną konkretyzacji dla odpowiednich szablonów klas:

template class X<int>; // You should add this to make your program build, 
         // or instantiate the corresponding class template 
         // specialization and invoke the foo() method in the 
         // same translation unit (A.cpp) 

W ogóle, chyba że jesteś napotykając na poważne problemy z kompilacją, sugerowałbym, abyś postępował zgodnie z powszechną praktyką i umieścił wszystko w pliku nagłówkowym, który ma być włączony przez wszystkie jednostki tłumaczeniowe, które muszą używać szablonu klasy:

///////////////////// file A.hpp ///////////////////// 

#include <iostream> 

template <typename T> 

class A 
{ 
public: 
    void foo() 
    { 
     std::cerr << "error: called generic foo " << std::endl ; 
    } 
}; 

template <> 
void A<int>::foo() 
{ 
    std::cerr << "calling <int> version of foo" << std::endl; 
} 

///////////////////// file main.cpp ///////////////////// 
#include "A.hpp" 

int main(int argc , char** argv) 
{ 
    A<int>* a = new A<int>(); 
    a->foo(); 
    return 0; 
} 

Jeśli napotkasz naprawdę straszne problemy z kompilacją, możesz oddzielić definicje funkcji składowych i umieścić je w oddzielnych jednostkach tłumaczeniowych z jawnymi instancjami, ale w C++ 11 nie ma czystego/łatwego sposobu na upewnienie się, wszystkie specjalizacje, które usuniesz w oddzielnych plikach .cpp, są zadeklarowane natychmiast po szablonie podstawowym (zgodnie z zaleceniami dobrej praktyki). Gdyby tak było, myślę, że byłby tak popularny, że nie musiałbyś tu przychodzić i pytać o to, ponieważ każdy z nas musi się zmierzyć z takim problemem.

W niektórych przypadkach niektóre fantazyjne makra mogą pomóc, ale z pewnością przyniosłyby więcej korzyści niż bóle konserwacyjne w naprawdę złożonych projektach.

Rozwiązaniem tego problemu została podjęta w standardzie C++ 03 poprzez wprowadzenie słowa kluczowego export, ale doświadczenie realizacja okazała się ona zbyt mocno wspierać sprzedawców kompilatora, dlatego export ma więcej części C++ Standard (od C++ 11).

Mamy nadzieję, że lepsze rozwiązanie dla modułów : spowoduje przejście do C++ 14 i udostępnienie rozwiązania do projektowania szablonów.

Answer 2

Myślę, że najlepsze, co można zrobić, to static_assert, że ogólny szablon nigdy nie jest tworzony z typami, które mają być wyspecjalizowane.

Poniższy kod służy tylko do zilustrowania - prawdopodobnie użyłbym BOOST_STATIC_ASSERT (i std::is_same, gdybym mógł użyć C++ 11). Podstawową ideą jest zapobieganie niejawnemu tworzeniu instancji niespecjalistycznego szablonu z zestawem typów, których nie możesz zabronić. Oczywiście, jeśli zapomnisz dodać statyczny dowództwo ORAZ specjalizację, której wciąż nie uda.

template<class T, class U> 
struct is_same { enum { value = false }; }; 

template<class T> 
struct is_same<T, T> { enum { value = true }; }; 

template <bool enable> 
struct StaticAsserter 
{ 
    char test[enable]; 
}; 

template <typename T> 
struct foo 
{ 
    // Make sure we can't implicit instantiate foo for int. 
    StaticAsserter<!is_same<int, T>::value> DisallowInt; 
}; 

int main() 
{ 
    foo<unsigned> hi; 
    foo<int> fail; 

    return 0; 
} 

Answer 3

Sposób, aby mieć pewność, to jest nie dostarcza żadnej definicji generycznego szablonu foo(). Nie ma potrzeby deklarowania specjalizacje gdy robisz to w ten sposób:

// A.h 
template <typename T> struct A { void foo(); }; 

// main.cc 
#include "A.h" 
int main (int c, char **v) 
{ 
    A<int>().foo(); 
    // A<long>().foo(); // this line will compile but not link 
} 

// A.cc 
#include <cstdio> 
#include "A.h" 
template<> void A<int>::foo() { puts("foo!"); } 

Answer 4

Okay, z uwagi instancji rodzajowego A<T>::foo() realizację niekoniecznie jest błąd, tylko wtedy, gdy dostarczyli specjalizację w innym miejscu.

Chcemy znaleźć instancje generycznych szablonów, których nazwy są duplikatami specjalizacji, które powinny być tworzone tylko na konkretnej liście plików obiektów kompilatora - co ogranicza szukanie pasujących pól w dwóch zestawach danych. Do tego istnieje join:

# every object and where it's defined 
nm -A *.o | c++filt | grep ' T ' \ 
| sort -k3 > @all.definitions 

# definitions that shouldn't be duplicated: 
nm -A A-foo-int.o | c++filt | grep ' T ' \ 
| sort -k3 > @my.definitions 

# everything that shows on both lists: 
join -j3 @my.definitions @all.definitions 

edit: składnia sed za wzorce grep nie naprawdę działa bardzo dobrze.