Abbildung 1: Funktionsvorlagen

TemplHeader.h

template<typename T>
void f();

TemplCpp.cpp

template<typename T>
void f(){
   //...
}    
//explicit instantation
template void f<T>();

Main.cpp

#include "TemplHeader.h"
extern template void f<T>(); //is this correct?
int main() {
    f<char>();
    return 0;
}

Ist dies die richtige Verwendung extern templateoder verwende ich dieses Schlüsselwort nur für Klassenvorlagen wie in Abbildung 2?

Abbildung 2: Klassenvorlagen

TemplHeader.h

template<typename T>
class foo {
    T f();
};

TemplCpp.cpp

template<typename T>
void foo<T>::f() {
    //...
}
//explicit instantation
template class foo<int>;

Main.cpp

#include "TemplHeader.h"
extern template class foo<int>();
int main() {
    foo<int> test;
    return 0;
}

Ich weiß, dass es gut ist, all dies in eine Header-Datei zu packen, aber wenn wir Vorlagen mit denselben Parametern in mehreren Dateien instanziieren, haben wir mehrere gleiche Definitionen und der Compiler entfernt sie alle (außer einer), um Fehler zu vermeiden. Wie benutze ich extern template? Können wir es nur für Klassen verwenden oder können wir es auch für Funktionen verwenden?

Außerdem können Abbildung 1 und Abbildung 2 zu einer Lösung erweitert werden, bei der sich Vorlagen in einer einzelnen Header-Datei befinden. In diesem Fall müssen wir das extern templateSchlüsselwort verwenden, um mehrere gleiche Instanziierungen zu vermeiden. Gilt das auch nur für Klassen oder Funktionen?

Sie sollten nur verwenden extern template, um den Compiler zu zwingen, eine Vorlage nicht zu instanziieren, wenn Sie wissen, dass sie an einer anderen Stelle instanziiert wird. Es wird verwendet, um die Kompilierungszeit und die Größe der Objektdatei zu reduzieren.

Beispielsweise:

// header.h

template<typename T>
void ReallyBigFunction()
{
    // Body
}

// source1.cpp

#include "header.h"
void something1()
{
    ReallyBigFunction<int>();
}

// source2.cpp

#include "header.h"
void something2()
{
    ReallyBigFunction<int>();
}

Dies führt zu folgenden Objektdateien:

source1.o
    void something1()
    void ReallyBigFunction<int>()    // Compiled first time

source2.o
    void something2()
    void ReallyBigFunction<int>()    // Compiled second time

Wenn beide Dateien miteinander verknüpft sind, void ReallyBigFunction<int>()wird eine verworfen, was zu einer Verschwendung von Kompilierungszeit und Objektdateigröße führt.

Um Kompilierungszeit und Objektdateigröße nicht zu verschwenden, gibt es ein externSchlüsselwort, mit dem der Compiler keine Vorlagenfunktion kompiliert. Sie sollten dies genau dann verwenden, wenn Sie wissen, dass es in derselben Binärdatei an einer anderen Stelle verwendet wird.

Wechseln source2.cppzu:

// source2.cpp

#include "header.h"
extern template void ReallyBigFunction<int>();
void something2()
{
    ReallyBigFunction<int>();
}

Führt zu folgenden Objektdateien:

source1.o
    void something1()
    void ReallyBigFunction<int>() // compiled just one time

source2.o
    void something2()
    // No ReallyBigFunction<int> here because of the extern

Wenn beide miteinander verknüpft werden, verwendet die zweite Objektdatei nur das Symbol aus der ersten Objektdatei. Keine Notwendigkeit zum Verwerfen und keine verschwendete Kompilierungszeit und Objektdateigröße.

Dies sollte nur innerhalb eines Projekts verwendet werden, wie in Zeiten, in denen Sie eine Vorlage vector<int>mehrmals verwenden, sollten Sie sie externin allen außer einer Quelldatei verwenden.

Dies gilt auch für Klassen und Funktionen als eine und sogar für Vorlagenelementfunktionen.

Wikipedia hat die beste Beschreibung

In C ++ 03 muss der Compiler eine Vorlage instanziieren, wenn eine vollständig angegebene Vorlage in einer Übersetzungseinheit gefunden wird. Wenn die Vorlage in vielen Übersetzungseinheiten mit denselben Typen instanziiert wird, kann dies die Kompilierungszeiten erheblich verlängern. In C ++ 03 kann dies nicht verhindert werden. Daher wurden in C ++ 11 externe Vorlagendeklarationen eingeführt, die den externen Datendeklarationen entsprechen.

C ++ 03 hat diese Syntax, um den Compiler zu verpflichten, eine Vorlage zu instanziieren:

  template class std::vector<MyClass>;

C ++ 11 bietet jetzt folgende Syntax:

  extern template class std::vector<MyClass>;

Dies weist den Compiler an, die Vorlage in dieser Übersetzungseinheit nicht zu instanziieren.

_{^{Die Warnung: nonstandard extension used...}}

Microsoft VC ++ hatte bereits seit einigen Jahren eine nicht standardmäßige Version dieser Funktion (in C ++ 03). Der Compiler warnt davor, um Portabilitätsprobleme mit Code zu vermeiden, die auch auf verschiedenen Compilern kompiliert werden mussten.

Schauen Sie sich das Beispiel auf der verlinkten Seite an, um festzustellen, dass es ungefähr genauso funktioniert. Sie können davon ausgehen, dass die Nachricht bei zukünftigen Versionen von MSVC nicht mehr angezeigt wird, außer natürlich, wenn Sie gleichzeitig andere nicht standardmäßige Compiler-Erweiterungen verwenden.

extern template wird nur benötigt, wenn die Vorlagendeklaration vollständig ist

Dies wurde in anderen Antworten angedeutet, aber ich denke, es wurde nicht genug Wert darauf gelegt.

Dies bedeutet, dass in den OP-Beispielen dies extern templatekeine Auswirkung hat, da die Vorlagendefinitionen in den Headern unvollständig waren:

• void f();: nur Erklärung, kein Körper
• class foo: deklariert Methode f(), hat aber keine Definition

Daher würde ich empfehlen, extern templatein diesem speziellen Fall nur die Definition zu entfernen : Sie müssen sie nur hinzufügen, wenn die Klassen vollständig definiert sind.

Beispielsweise:

TemplHeader.h

template<typename T>
void f();

TemplCpp.cpp

template<typename T>
void f(){}

// Explicit instantiation for char.
template void f<char>();

Main.cpp

#include "TemplHeader.h"

// Commented out from OP code, has no effect.
// extern template void f<T>(); //is this correct?

int main() {
    f<char>();
    return 0;
}

Kompilieren und Anzeigen von Symbolen mit nm:

g++ -std=c++11 -Wall -Wextra -pedantic -c -o TemplCpp.o TemplCpp.cpp
g++ -std=c++11 -Wall -Wextra -pedantic -c -o Main.o Main.cpp
g++ -std=c++11 -Wall -Wextra -pedantic -o Main.out Main.o TemplCpp.o
echo TemplCpp.o
nm -C TemplCpp.o | grep f
echo Main.o
nm -C Main.o | grep f

Ausgabe:

TemplCpp.o
0000000000000000 W void f<char>()
Main.o
                 U void f<char>()

und dann sehen man nmwir, dass Udies undefiniert bedeutet, so dass die Definition nur TemplCppwie gewünscht beibehalten wurde.

All dies läuft auf den Kompromiss vollständiger Header-Deklarationen hinaus:

• Upsides:
  • ermöglicht externem Code die Verwendung unserer Vorlage mit neuen Typen
  • Wir haben die Möglichkeit, keine expliziten Instanziierungen hinzuzufügen, wenn das Aufblähen von Objekten in Ordnung ist
• Nachteile:
  • Bei der Entwicklung dieser Klasse führen Änderungen an der Header-Implementierung dazu, dass Smart-Build-Systeme alle Includer neu erstellen. Dies können viele, viele Dateien sein
  • Wenn wir das Aufblähen von Objektdateien vermeiden möchten, müssen wir nicht nur explizite Instanziierungen durchführen (wie bei unvollständigen Header-Deklarationen), sondern auch extern templatejeden Einschluss hinzufügen , was Programmierer wahrscheinlich vergessen werden

Weitere Beispiele hierfür finden Sie unter: Explizite Vorlageninstanziierung - wann wird sie verwendet?

Da die Kompilierungszeit in großen Projekten so wichtig ist, würde ich unvollständige Vorlagendeklarationen dringend empfehlen, es sei denn, externe Parteien müssen Ihren Code unbedingt mit ihren eigenen komplexen benutzerdefinierten Klassen wiederverwenden.

In diesem Fall würde ich zunächst versuchen, Polymorphismus zu verwenden, um das Problem der Erstellungszeit zu vermeiden, und Vorlagen nur verwenden, wenn spürbare Leistungssteigerungen erzielt werden können.

Getestet in Ubuntu 18.04.

Das bekannte Problem mit den Vorlagen ist das Aufblähen von Code, was die Folge der Generierung der Klassendefinition in jedem Modul ist, das die Spezialisierung auf Klassenvorlagen aufruft. Um dies zu verhindern, könnte man ab C ++ 0x das Schlüsselwort extern vor der Spezialisierung auf Klassenvorlagen verwenden

#include <MyClass>
extern template class CMyClass<int>;

Die explizite Instanziierung der Vorlagenklasse sollte nur in einer einzelnen Übersetzungseinheit erfolgen, vorzugsweise in der mit Vorlagendefinition (MyClass.cpp).

template class CMyClass<int>;
template class CMyClass<float>;

Wenn Sie extern zuvor für Funktionen verwendet haben, wird für Vorlagen genau dieselbe Philosophie befolgt. Wenn nicht, kann es hilfreich sein, für einfache Funktionen nach außen zu gehen. Möglicherweise möchten Sie auch die externen Elemente in die Header-Datei einfügen und den Header bei Bedarf einfügen.