Faciliter l'intégration d'une bibliothèque

Bonjour,

j'ai implémenté une bibliothèque mylib que j'aimerais diffuser. Cette bibliothèque effectue plusieurs tâches également réalisées par une autre bibliothèque otherlib déjà disponible et dont je ne suis pas l'auteur. Supposons qu'un développeur souhaite intégrer ces deux bibliothèques dans un code en laissant libre choix à ses utilisateurs d'utiliser mylib ou otherlib. Pour gérer ce genre de choses, j'ai l'habitude de voir des instructions pré-processorales du type

Code:

---

1 2 3 4 5 6 7

#ifdef MYLIB // définitions à partir de mylib #else #ifdef OTHERLIB // définitions à partir de otherlib #endif #endif

---

J'ai deux questions à ce sujet :
1. existe-t-il un mécanisme équivalent correspondant mieux à la philosophie C++?
2. si la réponse à 1. est négative, où définir MYLIB dans ma bibliothèque? En forçant l'inclusion d'un fichier d'en-tête mylib.h ou peut-on s'en passer?

Merci beaucoup!

Citation:

---

Envoyé par Aleph69

1. existe-t-il un mécanisme équivalent correspondant mieux à la philosophie C++?

---

Oui, les namespace http://cpp.developpez.com/faq/cpp/?page=namespace
Chaque bibliothèque écrit ces fonctions dans son propre namespace.
L'utilisateur peut faire un #include des deux bibliothèques dans un même fichier et utiliser les fonctions de cette façon lib0::fct() lib1::fct()
Il peut aussi faire un using namespace d'une des bibliothèques (à utiliser de façon limitée) comme dans using namespace std;.

Oui, bien sûr j'utilise déjà des espaces de noms. J'ai peut-être mal formulé mon problème. Je ne cherche pas à contourner un éventuel conflit entre les deux bibliothèques. Je cherche à faciliter l'intégration de ma bibliothèque au sens où le code du développeur en question doit pouvoir compiler même si son utilisateur ne possède pas ma bibliothèque.

Citation:

---

Envoyé par Aleph69

Je cherche à faciliter l'intégration de ma bibliothèque au sens où le code du développeur en question doit pouvoir compiler même si son utilisateur ne possède pas ma bibliothèque.

---

Pour facilier l'intégration, tu peux mettre la bibliothèque directement dans le projet voire en static. Ou si possible tu écris une bibliothèque uniquement avec des fichiers d'entête (header-only).

En tout cas, ce n'est pas à l'auteur de la bibliotèque de s'occuper de ça. Si un utilisateur veut utiliser, ta bibliothèque il le fera surtout si elle est facile d'intégration.

Je ne connais pas de mécanisme plus C++ que les #if defined(VAR) pour gérer les #include. Tu peux aussi voir du coter du Makefile ou de CMake pour compiler le bon fichier au lieu d'un autre mais je ne suis pas sûr que ce soit plus propre.

En C++, on préférera : (^^)

Code:

---

1 2 3

#if defined(MY_LIB) // ... #endif

---

Citation:

---

Envoyé par Ehonn

En tout cas, ce n'est pas à l'auteur de la bibliotèque de s'occuper de ça.

---

Je ne vois pas du tout ce qui te permet d'affirmer cela mais, pour toutes celles que j'ai été amené à utiliser, les auteurs s'en sont occupés. Je crois qu'il y a un malentendu sur la problématique.

Citation:

---

Envoyé par Ehonn

Je ne connais pas de mécanisme plus C++ que les #if defined(VAR) pour gérer les #include.

---

Je ne cherche pas du tout à faire cela! Oublions le C++ un moment. Imaginons que le développeur en question ait besoin d'une fonction openfile ouvrant un fichier. Il peut implémenter sa propre fonction myopenfile ou appeler la fonction libopenfile1 d'une bibliothèque lib1 gratuite ou la fonction libopenfile2 d'une bibliothèque lib2 payante, ces deux dernières fonctions étant bien plus performantes, la payante l'étant encore plus. Un utilisateur n'ayant que des petits fichiers à traiter et en très petit nombre se contentera de myopenfile. Sinon, il choisira d'utiliser libopenfile1 ou bien libopenfile2 s'il en a les moyens. Pour gérer les trois possibilités, le développeur va en fait définir une fonction openfile qui correspondra à myopenfile, libopenfile1 ou libopenfile2 selon que l'une des deux bibliothèques est disponible ou pas. Pour cela, il doit pouvoir détecter la présence ou l'absence des bibliothèques et compiler un code différent en fonction de cela. Il paraît donc naturel de faire appel au préprocesseur.

Ma question est de savoir comment faire en sorte que la présence ou l'absence de ma bibliothèque soit détectable tout en respectant la philosophie C++.

J'avais ça dans un projet. 3 + 1 façons de créer des threads, 3 façons de faire une inversion de matrice, et une fonction optionnelle.
La détection des bibliothèques se faisait avec CMake; et si plusieurs choix étaient possibles, l'utilisateur pouvait choisir la façon de faire avec un paramètre de la ligne de commande. Le code correspondant aux façons possibles étaient "activé" ou "désactivé" avec des #if defined(VAR), avec VAR donné, ou pas, par CMake.

Le problème était que le CmakeLists faisait 500 lignes...
J'ai réduit ça à environ 50 lignes en générant plusieurs exécutables. Mais j'ai toujours les #if defined(VAR) lorsqu'il est plus simple de ne pas séparer le code en plusieurs fichiers.

Si c'est à la compilation que la différence doit etre faite, il peut peut-être utiliser des options de linkages différentes.

Avec gcc, ca donnerait -lexpensivelib, -lopenlib ou -lmylib selon que l'on souhaite utiliser libexpensivelib, libopenlib ou une lib perso, que l'on nommerait mylib

Bonjour Pierre,

le problème ne se situe pas au niveau des options passées à l'édition des liens. Pour éviter toute confusion, suppose que l'utilisateur récupère directement les sources de la bibliothèque sans passer par une bibliothèque statique ou dynamique. Il dispose donc d'un projet contenant les sources de ma bibliothèque et celles du code du développeur mais pas les sources de la bibliothèque concurrente.

Et bien, il n'a qu'a compiler les deux libs en statique, puis utiliser la lib de son choix...

Cela revient au meme que de l'inclusion de sources.

En tout cas, c'est la solution que je prendrai moi.

Salut,
Assez d'accord avec ce qui a été dit. Si j'ai bien compris ta question, c'est une problématique à gérer au niveau de la construction, i.e. via un CMake, une docs de compilation, un makefile, etc...

Bonjour 3DArchi,

Citation:

---

Envoyé par 3DArchi

Salut,
Assez d'accord avec ce qui a été dit. Si j'ai bien compris ta question, c'est une problématique à gérer au niveau de la construction, i.e. via un CMake, une docs de compilation, un makefile, etc...

---

Je ne vois en quoi cela permet de détecter l'absence ou la présence de ma bibliothèque. De plus, je ne fournis que les sources, pas de makefile.

Si j'ai bien compris, l'utilisateur veut une application A qui utilise soit ta bibliothèque B1 soit une autre bibliothèque B2.
L'utilisateur télécharge les sources de l'application A
L'utilisateur télécharge ta bibliothèque B1.
L'utilisateur veut générer l'application.

Ben, ça dépend grandement de comment A utilise B1. Et en général, ca se passe au niveau du makefile. Soit via CMake qui permet de générer du makefile en fonction justement de chose installée ou pas. Soit parce que tu fournis des makefile que le développeur de l'application A peut utiliser pour proposer ses propres makefile. Utilisation typique : tu proposes plusieurs makefile pour différents compilateur avec différentes options (librairie statique ou dynamique, multithread ou pas, etc..). Le développeur de l'application construit ses propres makefile en fonction de son besoin appelant le makefile de ta bibliothèque adaptée à son utilisation de celle-ci.

Il est très difficile de répondre de façon générique à ta question. Parce qu'il n'y a pas vraiment de réponse définie et que ça dépend du process d'utilisation.

Ou alors j'ai vraiment rien compris à ton besoin :aie:

Bonjour 3DArchi,

Citation:

---

Envoyé par 3DArchi

Si j'ai bien compris, l'utilisateur veut une application A qui utilise soit ta bibliothèque B1 soit une autre bibliothèque B2.
L'utilisateur télécharge les sources de l'application A
L'utilisateur télécharge ta bibliothèque B1.
L'utilisateur veut générer l'application.

---

Oui, mais le problème se situe plutôt au niveau du développeur de l'application A.

Citation:

---

Envoyé par 3DArchi

Ben, ça dépend grandement de comment A utilise B1.

---

A utilise l'une des fonctions communes à B1 et B2. J'entends pas communes des fonctions partageant un même prototypage et un même comportement mais pouvant être implémentées différemment avec des performances inégales.

Citation:

---

Envoyé par 3DArchi

Il est très difficile de répondre de façon générique à ta question. Parce qu'il n'y a pas vraiment de réponse définie et que ça dépend du process d'utilisation.

---

Dans ce cas, je peux préciser. Pour l'instant, l'approche que j'ai rencontrée à plusieurs reprises en langage C, est l'utilisation d'instructions pré-processorales pour effectuer des compilations conditionnelles. A un moment dans B1 doit apparaître

Code:

---

#define _B1_

---

et B2 doit apparaître

Code:

---

#define _B2_

---

pour pouvoir indiquer la présence de B1 ou B2 dans A. Si ces lignes n'apparaissent pas, on utilise un procédé équivalent pour le signaler à la compilation (via l'edi, un makefile, ...) de A. Ensuite, dans A, on va trouver quelque chose qui ressemble à

Code:

---

1 2 3 4 5 6 7 8 9

#ifdef _B2_ // utilisation de la fonction de B2 #else #ifdef _B1_ // utilisation de la fonction B1 #else // utilisation de la fonction native de A #endif #endif

---

Ton exemple des compilateurs est très bon; cela fonctionne aussi avec les systèmes d'exploitation, les instructions simd, les bibliothèques externes, etc. Seulement, dans tous ces cas, les macros _B1_ et _B2_ sont fournies (par ex, _WIN32_, _GNUC_,_MSVC_,etc). J'aimerais donc fournir la mienne. L'une de mes questions est où la définir.

Ma seconde question concerne la philosophie C++ du point de vue du développeur. J'aurais pensé a priori mais sans certitude qu'on utiliserait plutôt des templates pour appeler la bonne fonction de la bonne bibliothèque quand c'est nécessaire. Je n'ai pas essayé, je ne sais pas si c'est possible, ni si c'est conseillé, ni si c'est totalement idiot, mais on pourrait peut-être par exemple imaginer un mécanisme consistant à définir un fonction template paramétrée par un pointeur sur fonction qui serait partiellement spécialisé pour la fonction de B1, ou celle de B2 (le comportement par défaut étant celui où la fonction du développeur est appelée). Dans ce cas, il me paraîtrait judicieux de fournir mes propres pointeurs sur fonction avant déploiement de B1. Ce n'est qu'un exemple (sûrement maladroit d'ailleurs) pour préciser un peu ma question sur la philosophie C++ dans ce contexte.

J'espère que cette fois-ci mes questions seront suffisamment précises.

Bonjour, pour la définition de macro, ce n'est justement pas à toi de le faire mais au développeur de A. Chaque dev a son propre style à ce niveau. Et le seul endroit approprié pour définir ce genre de macros c'est dans les options de compilations, or seul le dev de A y a accès, et encore heureux.

Tu dis que B1 et B2 ont la même interface/headers/prototypes ? dans ce cas les macros sont totalement inutile, il suffit de linker avec B1 ou B2 et le code marche quelque soit la librairie choisie.

Les templates n'ont rien à voir là dedans.

Bonjour,

Citation:

---

Envoyé par germinolegrand

Bonjour, pour la définition de macro, ce n'est justement pas à toi de le faire mais au développeur de A. Chaque dev a son propre style à ce niveau. Et le seul endroit approprié pour définir ce genre de macros c'est dans les options de compilations, or seul le dev de A y a accès, et encore heureux.

---

Désolé, mais je ne comprends pas pourquoi cette approche serait préférable à l'autre. L'argument "chaque développeur a son style" ne me convainc pas du tout; j'ai l'impression de lire "surtout ne normalise pas la nomenclature de tes macros, on aime bien l'anarchie dans ce domaine". J'imagine bien que cela ne doit pas être cela, mais la portée de l'argument m'échappe. En plus, je ne vois pas ce qui l'empêche d'ignorer totalement mon choix de macro.

Citation:

---

Envoyé par germinolegrand

Tu dis que B1 et B2 ont la même interface/headers/prototypes ? dans ce cas les macros sont totalement inutile, il suffit de linker avec B1 ou B2 et le code marche quelque soit la librairie choisie.

Les templates n'ont rien à voir là dedans.

---

Au temps pour moi! Les prototypes diffèrent.

Bonjour Aleph69,

Ok.
Admettons que tu as un fichier d'en-tête B1.h contenant le service proposée par ta bibliothèque.

Soit le développeur de A.
1/Soit la bibliothèque B1 est physiquement accessible et alors au moment de s'en servir, A fait un include de B1.H

2/Soit la bibliothèque B1 est physiquement inaccessible et alors A ne doit surtout pas faire un include de B1.H sous peine d'erreur de compilation

De 2/, il s'en suit que la décision ne peut être fournie automatiquement par B1 mais est forcément une option de compilation de A.

A1.H

Code:

---

1 2 3

#ifdef USE_B1 // forcement défini dans les options de compil de A et impossible à retrouver depuis B1 #include "B1.h" #endif

---

Ensuite, sur l'utilisation, un DP Pont par exemple peut permettre l'utilisation unifiée de l'interface. Seule la construction du pont dépendrait d'une stratégie de compilation qui peut se faire avec les directives de compilations.

Très bon argument! :ccool:
Ce que je pensais faire n'a pas de sens! :aie:

Et alors, pour gérer l'appel à la bonne fonction, template ou pas?

Mmh...
Si les prototypes et l'architecture n'est pas la même, je vois mal comment les templates pourraient régler ce problème...

Mais tu soulèves en effet un problème intéressant pour ce qui est de la compatibilité de différentes librairies...

Il me semble que tu peux définir des fonctions qui si elles ne sont pas appelées, ne sont pas compilées. C'est je crois par exemple le cas lorsque tu fais des classes de politique. Je pensais que ce mécanisme pouvait permettre d'émuler une forme de compilation conditionnelle.

Même sans templates, un prototype de fonction dont la fonction n'est pas déclarée ne pose aucun problème.
Par contre pour ce qui est des classes c'est plus embêtant car d'une la définition doit contenir des détails internes (qui peuvent demander une lib tierce ou des dépendances quelles qu'elles soient...).

Ok. Donc, a priori, pas de mécanisme propre au C++.
Je passe en résolu.
Merci à tous!