Speichern von C ++ - Vorlagenfunktionsdefinitionen in einer CPP-Datei

Ich habe einen Vorlagencode, den ich lieber in einer CPP-Datei als inline im Header gespeichert hätte. Ich weiß, dass dies möglich ist, solange Sie wissen, welche Vorlagentypen verwendet werden. Zum Beispiel:

.h Datei

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

CPP-Datei

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

Beachten Sie die letzten beiden Zeilen - die Funktion foo :: do template wird nur mit ints und std :: strings verwendet. Diese Definitionen bedeuten also, dass die App verknüpft wird.

Meine Frage ist - ist das ein böser Hack oder funktioniert das mit anderen Compilern / Linkern? Ich verwende diesen Code derzeit nur mit VS2008, möchte ihn jedoch auf andere Umgebungen portieren.

Das von Ihnen beschriebene Problem kann durch Definieren der Vorlage in der Kopfzeile oder über den oben beschriebenen Ansatz gelöst werden.

Ich empfehle, die folgenden Punkte aus dem C ++ FAQ Lite zu lesen :

• Warum kann ich die Definition meiner Vorlagenklasse nicht von ihrer Deklaration trennen und in eine CPP-Datei einfügen?
• Wie kann ich Linkerfehler mit meinen Vorlagenfunktionen vermeiden?
• Wie hilft der C ++ - Schlüsselwortexport bei Vorlagenlinkerfehlern?

Sie gehen sehr detailliert auf diese (und andere) Vorlagenprobleme ein.

Für andere auf dieser Seite, die sich fragen, wie die richtige Syntax (wie ich) für die explizite Vorlagenspezialisierung (oder zumindest in VS2008) lautet, ist die folgende ...

In Ihrer .h-Datei ...

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

Und in Ihrer CPP-Datei

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

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

Dieser Code ist wohlgeformt. Sie müssen nur darauf achten, dass die Definition der Vorlage zum Zeitpunkt der Instanziierung sichtbar ist. Um den Standard zu zitieren, § 14.7.2.4:

Die Definition einer nicht exportierten Funktionsvorlage, einer nicht exportierten Elementfunktionsvorlage oder einer nicht exportierten Elementfunktion oder eines statischen Datenelements einer Klassenvorlage muss in jeder Übersetzungseinheit vorhanden sein, in der sie explizit instanziiert wird.

Dies sollte überall dort gut funktionieren, wo Vorlagen unterstützt werden. Die explizite Instanziierung von Vorlagen ist Teil des C ++ - Standards.

Ihr Beispiel ist korrekt, aber nicht sehr portabel. Es gibt auch eine etwas sauberere Syntax, die verwendet werden kann (wie von @ namespace-sid hervorgehoben).

Angenommen, die Vorlagenklasse ist Teil einer Bibliothek, die gemeinsam genutzt werden soll. Sollten andere Versionen der Vorlagenklasse kompiliert werden? Soll der Bibliotheksverwalter alle möglichen Vorlagenverwendungen der Klasse vorwegnehmen?

Ein alternativer Ansatz ist eine geringfügige Abweichung von dem, was Sie haben: Fügen Sie eine dritte Datei hinzu, die die Vorlagenimplementierungs- / Instanziierungsdatei ist.

foo.h Datei

// Standard header file guards omitted

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

foo.cpp Datei

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

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

foo-impl.cpp Datei

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

Die einzige Einschränkung ist, dass Sie dem Compiler mitteilen müssen, dass er kompilieren soll, foo-impl.cppanstatt dass foo.cppdas Kompilieren des letzteren nichts bewirkt.

Natürlich können Sie mehrere Implementierungen in der dritten Datei oder mehrere Implementierungsdateien für jeden Typ haben, den Sie verwenden möchten.

Dies ermöglicht viel mehr Flexibilität beim Freigeben der Vorlagenklasse für andere Zwecke.

Dieses Setup reduziert auch die Kompilierungszeiten für wiederverwendete Klassen, da Sie nicht in jeder Übersetzungseinheit dieselbe Headerdatei neu kompilieren.

Dies ist definitiv kein böser Hack, aber beachten Sie, dass Sie dies (die explizite Vorlagenspezialisierung) für jede Klasse / jeden Typ tun müssen, den Sie mit der angegebenen Vorlage verwenden möchten. Bei VIELEN Typen, die eine Vorlageninstanziierung anfordern, kann Ihre CPP-Datei VIELE Zeilen enthalten. Um dieses Problem zu beheben, können Sie in jedem Projekt, das Sie verwenden, eine TemplateClassInst.cpp verwenden, damit Sie besser steuern können, welche Typen instanziiert werden. Offensichtlich ist diese Lösung nicht perfekt (auch bekannt als Silver Bullet), da Sie möglicherweise die ODR brechen :).

Im neuesten Standard gibt es ein Schlüsselwort ( export), mit dem dieses Problem behoben werden kann. Es ist jedoch in keinem anderen mir bekannten Compiler als Comeau implementiert.

Siehe dazu die FAQ-Lite .

Dies ist eine Standardmethode zum Definieren von Vorlagenfunktionen. Ich denke, es gibt drei Methoden, die ich zum Definieren von Vorlagen lese. Oder wahrscheinlich 4. Jeder mit Vor- und Nachteilen.

1. In Klassendefinition definieren. Ich mag das überhaupt nicht, weil ich denke, dass Klassendefinitionen nur als Referenz dienen und leicht zu lesen sein sollten. Es ist jedoch viel weniger schwierig, Vorlagen in der Klasse zu definieren als außerhalb. Und nicht alle Vorlagendeklarationen sind gleich komplex. Diese Methode macht die Vorlage auch zu einer echten Vorlage.

2. Definieren Sie die Vorlage im selben Header, jedoch außerhalb der Klasse. Dies ist meistens mein bevorzugter Weg. Es hält Ihre Klassendefinition aufgeräumt, die Vorlage bleibt eine echte Vorlage. Es erfordert jedoch eine vollständige Benennung der Vorlagen, was schwierig sein kann. Außerdem steht Ihr Code allen zur Verfügung. Wenn Sie jedoch möchten, dass Ihr Code inline ist, ist dies der einzige Weg. Sie können dies auch erreichen, indem Sie am Ende Ihrer Klassendefinitionen eine INL-Datei erstellen.

3. Fügen Sie die Datei header.h und Implementation.CPP in Ihre main.CPP ein. Ich denke, so wird es gemacht. Sie müssen keine Vorinstanziierungen vorbereiten, es verhält sich wie eine echte Vorlage. Das Problem, das ich damit habe, ist, dass es nicht natürlich ist. Normalerweise schließen wir keine Quelldateien ein und erwarten diese auch nicht. Ich denke, da Sie die Quelldatei aufgenommen haben, können die Vorlagenfunktionen eingebunden werden.

4. Diese letzte Methode, wie sie veröffentlicht wurde, definiert die Vorlagen in einer Quelldatei, genau wie Nummer 3; Anstatt die Quelldatei einzuschließen, instanziieren wir die Vorlagen vorab auf diejenigen, die wir benötigen. Ich habe kein Problem mit dieser Methode und es ist manchmal nützlich. Wir haben einen großen Code, der nicht von Inline profitieren kann. Fügen Sie ihn einfach in eine CPP-Datei ein. Und wenn wir gemeinsame Instanziierungen kennen und sie vordefinieren können. Dies erspart uns, 5, 10 Mal im Grunde dasselbe zu schreiben. Diese Methode hat den Vorteil, dass unser Code geschützt bleibt. Ich empfehle jedoch nicht, winzige, regelmäßig verwendete Funktionen in CPP-Dateien einzufügen. Dies verringert die Leistung Ihrer Bibliothek.

Beachten Sie, dass mir die Folgen einer aufgeblähten obj-Datei nicht bekannt sind.

Ja, dies ist die Standardmethode für die explizite Instanziierung von Spezialisierungen . Wie Sie angegeben haben, können Sie diese Vorlage nicht mit anderen Typen instanziieren.

Bearbeiten: basierend auf Kommentar korrigiert.

Nehmen wir ein Beispiel, aus irgendeinem Grund möchten Sie eine Vorlagenklasse haben:

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

Wenn Sie diesen Code mit Visual Studio kompilieren, funktioniert er sofort. gcc erzeugt einen Linkerfehler (wenn dieselbe Header-Datei aus mehreren CPP-Dateien verwendet wird):

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

Es ist möglich, die Implementierung in eine CPP-Datei zu verschieben, aber dann müssen Sie die Klasse wie folgt deklarieren:

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

Und dann sieht .cpp so aus:

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

Ohne zwei letzte Zeilen in der Header-Datei funktioniert gcc einwandfrei, aber Visual Studio erzeugt einen Fehler:

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

Die Syntax der Vorlagenklasse ist optional, wenn Sie die Funktion über den DLL-Export verfügbar machen möchten. Dies gilt jedoch nur für die Windows-Plattform. Daher könnte test_template.h folgendermaßen aussehen:

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

mit .cpp-Datei aus dem vorherigen Beispiel.

Dies bereitet dem Linker jedoch mehr Kopfschmerzen. Es wird daher empfohlen, das vorherige Beispiel zu verwenden, wenn Sie die DLL-Funktion nicht exportieren.

Zeit für ein Update! Erstellen Sie eine Inline-Datei (.inl oder wahrscheinlich eine andere) und kopieren Sie einfach alle Ihre Definitionen darin. Stellen Sie sicher, dass Sie die Vorlage über jeder Funktion hinzufügen ( template <typename T, ...>). Anstatt die Header-Datei in die Inline-Datei aufzunehmen, machen Sie jetzt das Gegenteil. Fügen Sie die Inline-Datei nach der Deklaration Ihrer Klasse ein ( #include "file.inl").

Ich weiß nicht wirklich, warum das niemand erwähnt hat. Ich sehe keine unmittelbaren Nachteile.

An dem Beispiel, das Sie gegeben haben, ist nichts auszusetzen. Aber ich muss sagen, ich glaube, es ist nicht effizient, Funktionsdefinitionen in einer CPP-Datei zu speichern. Ich verstehe nur die Notwendigkeit, die Deklaration und Definition der Funktion zu trennen.

In Verbindung mit der expliziten Klasseninstanziierung kann Ihnen die Boost Concept Check Library (BCCL) dabei helfen, Vorlagenfunktionscode in CPP-Dateien zu generieren.

Keiner der oben genannten Punkte hat für mich funktioniert. Hier ist, wie Sie ihn gelöst haben. Meine Klasse hat nur eine Methode als Vorlage.

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

Dadurch werden Linkerfehler vermieden und TemporaryFunction muss überhaupt nicht aufgerufen werden