pimpl et template

Version imprimable

pimpl et template

Bonjour,

imaginons que nous travaillons sur une biblioth�que. Nous voulons donc, id�alement, exporter un seul en-t�te qui propose le protocole (ensemble des fonctions et variables publiques) et cacher l'impl�mentation en elle m�me.
Pour ce faire, rien de tel qu'un classique pimpl:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 /***** my_lib.h ********/ class MyLibImpl; class MyLib { public: // protocol void DoSomething(); // ... private: MyLibImpl * pimpl_; // pimpl: tout sera implémenté dans cette classe int a_super_important_value; }; /***** my_lib.cpp ********/ #include "my_lib.h" #include "my_lib_impl.h" void MyLib::DoSomething() { pimpl->DoSomething(); }
Vous noterez la pr�sence de cette variable membre priv�e: a_super_important_value. Elle est type int.

Donc imaginons que nous avons impl�ment� notre lib, que �a marche qu'on est pr�t � lancer des tests en pr�-prod. Et l�, subitement, le commercial nous appelle et nous explique que finalement, cette super_important_value ne sera pas forc�ment un entier, mais d'un type ind�termin� (donc pas forc�ment natif) que le client doit pouvoir choisir. Les commerciaux sont tr�s forts, et dans cette situation hypoth�tique, nous nous sommes laiss� convaincre, sans m�me s'en rendre compte, que c'�tait une bonne id�e, et c'�tait pas bien grave de pr�venir alors que le code �tait finit.

Ok donc, pas de probl�me, gr�ce au c++ on peut tout faire. Pour ce probl�me l�, on a les templates. Je vais transformer ma classe en template et �a va rouler tout seul:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 /***** my_lib.h ********/ class MyLibImpl; template <typename T> class MyLib { public: // protocol void DoSomething(); // ... private: MyLibImpl * impl_; // pimpl: tout sera implémenté dans cette classe T a_super_important_value; };
Sauf que non, on me fait signe que c'est pas possible! Et pour une raison toute b�te: le code d'une classe template doit �tre dans l'en-t�te (ou inclure le cpp � la fin de l'en-t�te ce qui revient au m�me). Et donc �a casse mon pimpl.

Savez-vous quelles sont les solutions pour se sortir de cette situation � peu de frais?

18/01/2013, 12h55
koala01

Salut,

De mani�re g�n�rale, ce qui importe dans pimpl, c'est l'interface de ta classe qui le g�re... Le fait que le code qui permet l'appel des diff�rentes fonctions soit dans un fichier cpp ou dans le fichier d'en-t�te pour cause de besoin d'inlining ne pose pas vraiment de probl�me majeur.

Le probl�me auquel tu pourrait �ventuellement �tre confront�, c'est si tu t'appr�tes � fournir une biblioth�que dynamique et qu'il faut que tout le code correspondant soit bel et bien accessible depuis la biblioth�que.

Dans ce cas, je partirais sans doute du principe que le type de a_super_important_value doit, quoi qu'il en soit, proposer une interface propre (sans doute proche de ce que l'on peut obtenir avec des valeurs num�riques), et j'envisagerais l'utilisation de l'instanciation explicite pour "tout type connu correspondant" � cette interface, en gardant en t�te le fait que cela correspondra � une augmentation sans doute substantielle de taille de la biblioth�que...
18/01/2013, 13h46
r0d

Citation:

Envoy� par koala01

De mani�re g�n�rale, ce qui importe dans pimpl, c'est l'interface de ta classe qui le g�re... Le fait que le code qui permet l'appel des diff�rentes fonctions soit dans un fichier cpp ou dans le fichier d'en-t�te pour cause de besoin d'inlining ne pose pas vraiment de probl�me majeur.

En fait non, ce qui importe dans mon cas, c'est que l'en-t�te que je fournis (MyLib.h) ne doit inclure aucun autre fichier de ma lib. Car l'id�e c'est de fournir au client le .lib/.a (ce sera une lib statique et pis c'est tout) et un seul et unique en-t�te. Si MyLib.h inclus d'autres en-t�tes, il faut alors fournir ces en-t�tes �galement, et c'est ce que je souhaite �viter.
18/01/2013, 13h56
koala01

La question est alors : de quels type est susceptible d'�tre a_super_important_value :question:

A priori, les types devraient ne pas �tre si nombreux que cela dans le sens o� cette variable �tait pr�vue � l'origine pour �tre une valeur num�rique enti�re.

Je serais donc relativement surpris si tu devais pr�voir beaucoup plus que les treize types primitifs et quelque chose ressemblant � std::complex.

Dans de telles conditions, tu devrais pouvoir envisager l'instanciation explicite pour ces diff�rents types et donc consid�rer les impl�mentations des diff�rentes fonctions comme internes (en n'incluant le fichier qui les impl�mente que dans le fichier qui provoque l'instanciation explicite ;) )
18/01/2013, 13h57
Bousk

Sinon y'a peut-�tre une "astuce" crade pour �viter le template, qui est de mettre a_super_important_value en void*
En fournissant qqs m�thodes pour manipuler �a (une m�thode template qui r�alise le transtypage par exemple).

:aie: :zoubi:
18/01/2013, 14h07
r0d

Citation:

Envoy� par koala

Dans de telles conditions, tu devrais pouvoir envisager l'instanciation explicite pour ces diff�rents types

Tu as d� louper 4 mots dans mon message initial:

Citation:

Savez-vous quelles sont les solutions pour se sortir de cette situation � peu de frais?

:aie:

Non mais plus s�rieusement, le probl�me c'est qu'apparemment, ils veulent y injecter des objets � eux, et je n'ai pas la moindre id�e de ce que �a peut �tre. La seule chose que je sais, c'est que ces objets impl�menterons les op�rateurs de bases (+,-,*,/) ainsi que les op�rateurs de flux.

Citation:

Envoy� par Bousk

Sinon y'a peut-�tre une "astuce" crade pour �viter le template, qui est de mettre a_super_important_value en void*
En fournissant qqs m�thodes pour manipuler �a (une m�thode template qui r�alise le transtypage par exemple).

:aie: :zoubi:

Herb Sutter dit que cette m�thode c'est tr�s beaucoup pas bien! :calim2:
Mais bon, j'ai peur que ce ne soit la seule solution malheureusement :?
18/01/2013, 14h40
ternel

Tu peux peut-�tre utiliser le triplet interface + template + static_assert (ou boost::concept, je crois)

Puis d�finir une classe de Nombre et des wrappers directs pour les types de bases
Il te suffirait d'avoir un pointeur de ce Nombre
18/01/2013, 14h41
cob59

A mon avis, le probl�me se situe dans le cahier des charges plus que dans le code lui-m�me. Si on ne sait pas � l'avance quels types circulent dans notre API, c'est que le besoin du client n'est pas suffisamment bien d�fini, point.
18/01/2013, 14h45
Klaim

En fait, tu dois

1. separer tout ce qui est pas dependant du type en paramettre dans des types non-template (par exemple si l'implementation a pas besoin du type, tu peux garder un pointeur ca ira)
2. avoir tout ce qui est dependant du type dans le header.

Donc on peut pas te repondre clairement sans savoir si a_super_important_value est exploite dans toutes les methodes de MyLibImpl.

Si oui, alors t'as pas d'autre choix que je tout ecrire en template.
Si non, alors tu as une separation claire entre le code qui en a besoin et le reste. Mets le reste dans les cpp, et le code dependant du type dans le header.
18/01/2013, 16h57
Iradrille

D�clarer a_super_important_value de type boost::any peut �tre une solution rapide � mettre en place.
Le principal inconv�nient est que l'utilisateur de la lib devra compiler avec boost.
18/01/2013, 17h17
cob59

Citation:

Envoy� par Iradrille

D�clarer a_super_important_value de type boost::any peut �tre une solution rapide � mettre en place.
Le principal inconv�nient est que l'utilisateur de la lib devra compiler avec boost.

Et en priant pour que la lib et l'appli "h�te" soient compil�es avec des compilos identiques de versions identiques...
18/01/2013, 17h28
Iradrille

Citation:

Envoy� par cob59

Et en priant pour que la lib et l'appli "h�te" soient compil�es avec des compilos identiques de versions identiques...

Tu peux expliquer ?

Me semblais que le probl�me de compilos diff�rents c'�tait juste au niveau du mangling ?
18/01/2013, 17h44
cob59

Citation:

Envoy� par Iradrille

Tu peux expliquer ?

Me semblais que le probl�me de compilos diff�rents c'�tait juste au niveau du mangling ?

Si une app et une DLL s'�changent une std::string mais que l'une et l'autre l'impl�mentent diff�remment, il y aura forc�ment de la casse. Cf cette r�ponse de quelqu�un qui l'explique mieux que moi.

En r�gle g�n�rale, une API "portable" ne peut exporter que des types primitifs, des pointeurs et des classes d�clar�es � m�me le header.
18/01/2013, 18h06
Iradrille

Mais ici, sauf erreur de ma part, boost::any est d�fini enti�rement dans des headers, �a ne devrait pas poser de probl�mes ?
(tant que la version de boost de l'h�te est >= � celle utilis�e pour compiler la lib)

Mais oui, boost::any n'est pas la solution id�ale, on est d'accord.
18/01/2013, 18h51
cob59

Il faut garder � l'esprit que les headers ont pour seule vocation d'�tre inclus dans des .cpp, � savoir ceux de la DLL et ceux de l'appli client. Ces .cpp vont �tre compil�s avec 2 unit�s de compilation diff�rentes donc, bien que boost::any soit enti�rement d�fini dans un header, rien ne garantit que le boost::any produit par le client sera compatible avec le boost::any lu par la DLL.

Il y aurait une chance si boost::any �tait un type POD, ce qui n'est pas le cas.
Il suffirait que boost::any appelle le moindre new/delete/malloc/realloc/free d'une part et d'autre de l'interface pour aboutir � un plantage.
18/01/2013, 21h40
Flob90

@OP: Quel est la d�pendance exacte des services fournit par le pimpl par rapport au template ? Il est envisageable d'isoler tout ce qui n'en d�pend pas en ajoutant une indirection (h�ritage).

Apr�s la pr�sence de services associ�s aux template imposent assez fortement de ne pouvoir totalement "cacher" l'impl�mentaiton. Cependant, c'est si grave que c� ?

@Iradrille: Par rapport au point relev� par cob59, de mani�re g�n�ral, la production d'une API C++ non "header only" et/ou non "extern C" ne produira pas une API totalement portable. C'est cependant � nuancer, il me semble que GCC produit un document relatif aux ABI qui permet d'assurer une compatibilit� partiel (backward) et est suivit par d'autre compilateur.

C'est d'ailleurs visible lors de l'utilisation de syst�mes Linux, il est fr�quent qu'une simple r�cup�ration d'une biblioth�que (binaire) via les d�pots fonctionne avec le compilateur du syst�me utilis�, alors qu'en toute rigeur il faudrait la recompiler pour le dit syst�me.
19/01/2013, 01h04
Klaim

Boost any ou n'importe quoi tant que le type n'est pas connu par la bibliotheque, ce que je dis est valable.
En fait je me suis une fois retrouve dans un cas similaire, j'ai lute pour sortir un max de code des template mais qui soient utilise par les template.

Au final je m'en suis sorti en realisant que tout le code n'avait pas besoin de connaitre toutes les infos de type, du coup je me suis retrouve avec du code template qui faisait appel a du code non-template.

Bonsoir,

Entre la template et le boost::any, il y a peut-�tre une interface � mettre en place pour le type de "a_super_important_value"?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
// abstraite extensible par l'utilisateur
class Value {
public:
    // interface
    virtual int toInteger() const = 0 ;
    // probablement un clone, etc. 
};
 
// predefinie
class Integer : public Value {
public:
     virtual int toInteger() const { return _value; }
private:
     int _value ;
};
 
// espece de pointeur intelligent sur Value (boost::any avec une interface), histoire de 
// conserver une sémantique par valeur malgré le polymorphisme sur Value.
class Variant {
public:
    // constructeur avec value & co
    // méthode qui ne connaissent que "Value" (operator, ->, *, & co) 
private:
    Value *_value ;
};

Et hop :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
class MyLibImpl;
 
class MyLib
{
public:
 
// protocol
   void DoSomething();
// ...
 
private:
   MyLibImpl * pimpl_; // pimpl: tout sera implémenté dans cette classe
   Variant a_super_important_value;
};

Tu n'acc�des qu'� l'interface de "Value", ton utilisateur peu faire un :

Code:

1
2
3
4
5
6
7
8
9
10
11
 
// predefinie
class MonType : public Value {
public:
     // implementation de l'interface de Value
     virtual int toInteger() const {
           return "cela ne nous regarde pas" ;
     }
private:
     // mes super variables membres ;
};

L�, tu devrais pouvoir garder pimpl sur MyLibImpl (chose qui a moins d'int�r�t sur "Value" vu que ton utilisateur veut pouvoir s'int�grer dans le syst�me).

Tu t'en sors normalement � moindre frais en rajoutant de "a_super_important_value->toInteger()" dans MyLib.cpp.

Non?