Stockage des définitions de fonction de modèle C ++ dans un fichier .CPP

J'ai un code de modèle que je préférerais avoir stocké dans un fichier CPP au lieu d'être intégré dans l'en-tête. Je sais que cela peut être fait tant que vous savez quels types de modèles seront utilisés. Par exemple:

fichier .h

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

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

Notez les deux dernières lignes - la fonction de modèle foo :: do n'est utilisée qu'avec les chaînes ints et std ::, donc ces définitions signifient que l'application sera liée.

Ma question est - est-ce un hack méchant ou cela fonctionnera-t-il avec d'autres compilateurs / linkers? J'utilise uniquement ce code avec VS2008 pour le moment, mais je souhaiterai porter sur d'autres environnements.

Le problème que vous décrivez peut être résolu en définissant le modèle dans l'en-tête ou via l'approche que vous décrivez ci-dessus.

Je recommande de lire les points suivants de la FAQ C ++ Lite :

• Pourquoi ne puis-je pas séparer la définition de ma classe de modèles de sa déclaration et la placer dans un fichier .cpp?
• Comment puis-je éviter les erreurs de l'éditeur de liens avec mes fonctions de modèle?
• Comment l'exportation de mots clés C ++ aide-t-elle avec les erreurs de l'éditeur de liens de modèle?

Ils entrent dans beaucoup de détails sur ces problèmes de modèle (et d'autres).

Pour d'autres sur cette page qui se demandent quelle est la syntaxe correcte (comme je l'ai fait) pour la spécialisation explicite de modèles (ou au moins dans VS2008), c'est la suivante ...

Dans votre fichier .h ...

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

Et dans votre fichier .cpp

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

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

Ce code est bien formé. Il suffit de faire attention à ce que la définition du modèle soit visible au moment de l'instanciation. Pour citer la norme, § 14.7.2.4:

La définition d'un modèle de fonction non exporté, d'un modèle de fonction membre non exporté ou d'une fonction membre non exportée ou d'un membre de données statiques d'un modèle de classe doit être présente dans chaque unité de traduction dans laquelle il est explicitement instancié.

Cela devrait fonctionner correctement partout où les modèles sont pris en charge. L'instanciation de modèle explicite fait partie de la norme C ++.

Votre exemple est correct mais pas très portable. Il existe également une syntaxe légèrement plus propre qui peut être utilisée (comme indiqué par @ namespace-sid).

Supposons que la classe basée sur des modèles fasse partie d'une bibliothèque à partager. Faut-il compiler d'autres versions de la classe basée sur des modèles? Le responsable de la bibliothèque est-il censé anticiper toutes les utilisations possibles du modèle de la classe?

Une autre approche est une légère variation de ce que vous avez: ajoutez un troisième fichier qui est le fichier d'implémentation / d'instanciation du modèle.

fichier foo.h

// Standard header file guards omitted

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

fichier foo.cpp

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

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

Fichier foo-impl.cpp

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

La seule mise en garde est que vous devez dire au compilateur de compiler foo-impl.cppau lieu defoo.cpp compiler ce dernier ne fait rien.

Bien sûr, vous pouvez avoir plusieurs implémentations dans le troisième fichier ou avoir plusieurs fichiers d'implémentation pour chaque type que vous souhaitez utiliser.

Cela permet beaucoup plus de flexibilité lors du partage de la classe basée sur des modèles pour d'autres utilisations.

Cette configuration réduit également les temps de compilation pour les classes réutilisées car vous ne recompilez pas le même fichier d'en-tête dans chaque unité de traduction.

Ce n'est certainement pas un hack désagréable, mais sachez que vous devrez le faire (la spécialisation de modèle explicite) pour chaque classe / type que vous souhaitez utiliser avec le modèle donné. Dans le cas de nombreux types de demande d'instanciation de modèle, il peut y avoir BEAUCOUP de lignes dans votre fichier .cpp. Pour résoudre ce problème, vous pouvez avoir un TemplateClassInst.cpp dans chaque projet que vous utilisez afin d'avoir un meilleur contrôle sur les types qui seront instanciés. Évidemment, cette solution ne sera pas parfaite (alias la balle d'argent) car vous pourriez finir par casser l'ODR :).

Il existe, dans la dernière norme, un mot-clé ( export) qui aiderait à résoudre ce problème, mais il n'est implémenté dans aucun compilateur que je connaisse, à part Comeau.

Voir la FAQ à ce sujet.

Il s'agit d'un moyen standard de définir des fonctions de modèle. Je pense qu'il y a trois méthodes que je lis pour définir des modèles. Ou probablement 4. Chacun avec des avantages et des inconvénients.

1. Définissez dans la définition de classe. Je n'aime pas ça du tout parce que je pense que les définitions de classe sont strictement pour référence et devraient être faciles à lire. Cependant, il est beaucoup moins compliqué de définir des modèles en classe qu'à l'extérieur. Et toutes les déclarations de modèle ne sont pas au même niveau de complexité. Cette méthode fait également du modèle un véritable modèle.

2. Définissez le modèle dans le même en-tête, mais en dehors de la classe. C'est ma façon préférée la plupart du temps. Il garde votre définition de classe bien rangée, le modèle reste un vrai modèle. Cependant, cela nécessite une dénomination complète du modèle, ce qui peut être délicat. De plus, votre code est accessible à tous. Mais si vous avez besoin que votre code soit en ligne, c'est la seule façon. Vous pouvez également accomplir cela en créant un fichier .INL à la fin de vos définitions de classe.

3. Incluez le header.h et la mise en œuvre.CPP dans votre main.CPP. Je pense que c'est comme ça que c'est fait. Vous n'aurez pas à préparer de pré-instanciations, il se comportera comme un vrai modèle. Le problème que j'ai avec ça, c'est que ce n'est pas naturel. Normalement, nous n'incluons pas et nous prévoyons d'inclure des fichiers source. Je suppose que puisque vous avez inclus le fichier source, les fonctions du modèle peuvent être intégrées.

4. Cette dernière méthode, qui était la méthode publiée, définit les modèles dans un fichier source, tout comme le numéro 3; mais au lieu d'inclure le fichier source, nous pré-instancions les modèles à ceux dont nous aurons besoin. Je n'ai aucun problème avec cette méthode et elle est parfois utile. Nous avons un gros code, il ne peut pas bénéficier d'être intégré, alors mettez-le simplement dans un fichier CPP. Et si nous connaissons des instanciations communes et que nous pouvons les prédéfinir. Cela nous évite d'écrire essentiellement la même chose 5, 10 fois. Cette méthode a l'avantage de garder notre code propriétaire. Mais je ne recommande pas de mettre de minuscules fonctions régulièrement utilisées dans les fichiers CPP. Cela réduira les performances de votre bibliothèque.

Remarque, je ne suis pas au courant des conséquences d'un fichier obj gonflé.

Oui, c'est la manière standard de faire une instanciation explicite de spécialisation . Comme vous l'avez indiqué, vous ne pouvez pas instancier ce modèle avec d'autres types.

Edit: corrigé en fonction du commentaire.

Prenons un exemple, disons pour une raison quelconque que vous voulez avoir une classe de modèle:

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

Si vous compilez ce code avec Visual Studio - cela fonctionne immédiatement. gcc produira une erreur de l'éditeur de liens (si le même fichier d'en-tête est utilisé à partir de plusieurs fichiers .cpp):

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

Il est possible de déplacer l'implémentation vers un fichier .cpp, mais vous devez ensuite déclarer une classe comme celle-ci -

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

Et puis .cpp ressemblera à ceci:

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

Sans deux dernières lignes dans le fichier d'en-tête - gcc fonctionnera bien, mais Visual studio produira une erreur:

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

la syntaxe de classe de modèle est facultative dans le cas si vous souhaitez exposer la fonction via l'exportation .dll, mais cela ne s'applique qu'à la plate-forme Windows - donc test_template.h pourrait ressembler à ceci:

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

avec le fichier .cpp de l'exemple précédent.

Cependant, cela donne plus de maux de tête au lieur, il est donc recommandé d'utiliser l'exemple précédent si vous n'exportez pas la fonction .dll.

Il est temps pour une mise à jour! Créez un fichier en ligne (.inl, ou probablement tout autre) et copiez simplement toutes vos définitions dedans. Assurez-vous d'ajouter le modèle au-dessus de chaque fonction ( template <typename T, ...>). Maintenant, au lieu d'inclure le fichier d'en-tête dans le fichier en ligne, vous faites le contraire. Incluez le fichier en ligne après la déclaration de votre classe ( #include "file.inl").

Je ne sais pas vraiment pourquoi personne n'a mentionné cela. Je ne vois aucun inconvénient immédiat.

Il n'y a rien de mal avec l'exemple que vous avez donné. Mais je dois dire que je pense qu'il n'est pas efficace de stocker des définitions de fonctions dans un fichier cpp. Je comprends seulement la nécessité de séparer la déclaration et la définition de la fonction.

Lorsqu'elle est utilisée avec une instanciation de classe explicite, la bibliothèque de vérification de concept Boost (BCCL) peut vous aider à générer du code de fonction de modèle dans des fichiers cpp.

Rien de ce qui précède n'a fonctionné pour moi, alors voici comment y résolu, ma classe n'a qu'une seule méthode basée sur des modèles ..

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

cela évite les erreurs de l'éditeur de liens, et pas besoin d'appeler du tout TemporaryFunction