Discussion :

[r0d]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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?

[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...

[r0d]

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.

[koala01]

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

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 )

[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).

[r0d]

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:

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

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.

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

Herb Sutter dit que cette méthode c'est très beaucoup pas bien!
Mais bon, j'ai peur que ce ne soit la seule solution malheureusement

[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

[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.

[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.

[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.

[cob59]

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...

[Iradrille]

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 ?

[cob59]

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.

[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.

[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.

[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.

[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.

[bretus]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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?