Nous utiliserons le programme prog_calc.cpp ; il n'est constitué que de quelques appels à des fonctionnalités décrites dans un fichier d'en-tête calc.hpp afin de faire évoluer le contenu d'un tableau dynamique de réels en fonction de ce qui est saisi au clavier.

Essayons tout de suite de fabriquer ce programme avec la commande make ; nous constatons l'échec à cause du fichier d'en-tête calc.hpp qui est introuvable.
En effet, il est placé dans le sous-répertoire Calc qui fournit les fonctionnalités en questions.
Pour en informer le compilateur nous devons modifier le fichier GNUmakefile afin de compléter la première occurrence de la variable CPPFLAGS que nous trouvons : Ainsi, le préprocesseur du compilateur C/C++ sait qu'il est susceptible de trouver des fichiers à inclure dans ce répertoire.

Désormais, la compilation réussit, mais c'est l'édition de liens qui échoue : notre programme fait usage des fonctionnalités déclarées dans le fichier d'en-tête calc.hpp mais leur définition n'est toujours pas accessible.
Les définitions manquantes seront fournies par une bibliothèque dynamique ; nous pouvons voir ceci comme un programme compilé qui n'aurait pas de fonction main(), donc qui ne pourrait pas fonctionner seul (un autre programme doit en faire usage).

Pour ceci, plaçons nous dans le sous répertoire Calc pour fabriquer ce qui s'y trouve puis revenons à notre répertoire principal : $ cd Calc ↵ $ make ↵ $ cd .. ↵ Ce sous répertoire contient lui aussi un fichier GNUmakefile car l'idée est de construire une fois pour toute cette bibliothèque dynamique afin qu'elle devienne ensuite utilisable par n'importe quel autre programme qui en aurait besoin.
Vous devez d'ailleurs remarquer que l'option -shared est passée à l'édition de liens ; ça ne fabrique donc pas un programme mais bien une bibliothèque dont le nom est indiqué par l'option-o (libcalc.so, libcalc.dylib, calc.dll... selon le système).

De retour au répertoire de notre programme principal, il nous faut modifier son ficher GNUmakefile afin de compléter la première occurrence de la variable LDFLAGS que nous trouvons : Ainsi, l'éditeur de liens sait qu'il est susceptible de trouver des bibliothèques dans le répertoire Calc (option -L, majuscule), et qu'il doit lier l'exécutable avec la bibliothèque dont le nom symbolique est calc (option -l, minuscule).
Désormais, la fabrication du programme prog_calc doit aboutir sans encombre.

Au moment de l'exécuter, ce programme ne contient pas l'intégralité de son code exécutable mais sait qu'il peut l'obtenir en chargeant les bibliothèques dont il dépend juste avant d'invoquer la fonction main() ; c'est en cela que les bibliothèques en question sont dites dynamiques✍.
L'option -Wl,-rpath,Calc précisée juste avant sert à mémoriser à l'intérieur du programme exécutable un chemin vers un répertoire qui est susceptible de contenir les bibliothèques en question.
Cette information est prise en compte sous Linux, mais ce n'est malheureusement pas le cas pour tous les systèmes✍.
Si vous tentez d'exécuter ce programme sous Windows ou MacOSX par exemple, vous constaterez un message d'erreur indiquant l'impossibilité de retrouver la bibliothèque calc.dll ou libcalc.dylib dont il dépend.
Dans ce cas, nous fournirons alors l'information manquante par une variable d'environnement depuis le terminal ; sous Windows : C:\CRS_L15_DynLib> set PATH=Calc;%PATH% ↵ et sous MacOSX : $ export DYLD_LIBRARY_PATH="Calc:${DYLD_LIBRARY_PATH}" ↵ Dès lors, le programme doit fonctionner dans tous les cas.
Il se contente pour l'instant d'inviter à la saisie et d'afficher la pile des valeurs réelles qu'il a reconnues (en ignorant les autres mots).

Nous ne modifierons plus jamais le code source de ce programme principal et nous n'auront jamais plus besoin de le fabriquer à nouveau ; nous continuerons à l'utiliser tel qu'il est.
En revanche, puisqu'il utilise les fonctionnalités d'une bibliothèque dynamique, nous interviendrons sur cette bibliothèque et la refabriquerons autant de fois que nécessaire.
Dans le sous-répertoire Calc, modifiez légèrement le code source de la fonction prompt() de calc.cpp afin de remplacer le symbole ? par un mot ou un autre symbole de votre choix.
Fabriquez à nouveau cette bibliothèque dynamique et retournez exécuter votre programme sans même l'avoir refabriqué : vous constaterez que la modification de code source de cette bibliothèque a bien une incidence sur le fonctionnement du programme.
Cela illustre une nouvelle fois la raison pour laquelle que de telles bibliothèques sont qualifiées de dynamiques : les programmes qui en dépendent changent de comportement (selon les modifications des bibliothèques) alors qu'ils n'ont pas à être eux-mêmes modifiés.
Cette propriété est très intéressante si, par exemple, une bibliothèque est mise à jour pour améliorer ses performances ou sa fiabilité : tous les programmes qui en dépendent bénéficient implicitement de cette amélioration sans qu'il soit nécessaire de les modifier.

En l'état, notre programme ne fait pas grand chose d'intéressant : il invite à la saisie et affiche la pile des valeurs réelles qu'il a reconnues (en ignorant les autres mots).
Il s'agit en fait d'une calculatrice en notation polonaise inversée ; seulement, elle ne sait faire aucune opération...
Nous chercherons donc à lui fournir autant de nouvelles opérations que nous le souhaitons, sans jamais la modifier, grâce à un mécanisme d'extension par plugins.

Pour simplifier notre réalisation, les opérations seront saisies en toutes lettres, comme les mots Plus et Quit sur cet exemple : $ ./prog_calc ↵ stack: ? 2 3 stack: 2 3 ? Plus stack: 5 ? 6 7 Plus stack: 5 13 ? 2 Plus Plus stack: 20 ? Quit $ L'idée est donc de charger une bibliothèque dynamique dont le nom est déduit du nom d'opération saisi afin d'exécuter une fonction de cette bibliothèque dont le rôle sera d'influer sur les données de l'application pour réaliser l'opération attendue.

La différence essentielle entre l'usage que nous faisions juste avant d'une bibliothèque dynamique et celui que nous envisageons maintenant, tient dans l'aspect implicite ou explicite du chargement de cette bibliothèque.
Dans la situation précédente, le chargement de la bibliothèque calc est implicite car le programme ne peut simplement pas fonctionner sans sa présence ; d'ailleurs l'usage de cette bibliothèque est requis dans le procédé de fabrication.
Au contraire, dans ce que nous nous apprêtons à réaliser, ce n'est que lors de l'acquisition d'une information (la saisie au clavier dans cet exemple) que le programme décide de charger explicitement une bibliothèque dont il fera usage.

Pour réaliser ceci, nous devons intervenir sur le fichier calc.cpp qui constitue le code source de la bibliothèque calc sur laquelle repose notre programme.
La fonction apply_operation() est appelée lorsqu'un mot qui ne peut pas être interprété comme une valeur réelle a été saisi au clavier ; ce mot est représenté par le paramètre operation.
Lorsqu'elle sera complétée, cette fonction aura une influence sur le tableau dynamique de réels values et indiquera par un résultat booléen si le programme doit continuer à fonctionner ou s'arrêter.

Une première étape consiste à déterminer le nom de la bibliothèque que nous allons tenter de charger explicitement ; la fonction compose_library_name() a été dédiée ici à ce propos.
Nous choisissons arbitrairement dans cet exemple que le nom de la bibliothèque sera composé du préfixe Calc suivi du nom d'opération saisi ; par exemple CalcPlus pour l'opération Plus.
Toutefois, comme nous l'avons constaté dans la partie précédente, le nom exact de la bibliothèque est dépendant du système d'exploitation ce qui nécessite l'ajout d'un préfixe et/ou d'un suffixe ; par exemple libCalcPlus.so, libCalcPlus.dylib ou CalcPlus.dll pour l'opération Plus✍.
Enfin, et à nouveau de manière arbitraire, nous décidons que, pour faciliter l'organisation de nos fichiers, cette bibliothèque dynamique sera placée dans un répertoire ayant le même nom que nous avons choisi précédemment ; par exemple CalcPlus/libCalcPlus.so, CalcPlus/libCalcPlus.dylib ou CalcPlus/CalcPlus.dll pour l'opération Plus.

Une autre étape consiste à déterminer le nom de la fonction que nous chercherons à invoquer au sein de cette bibliothèque ; la fonction compose_function_name() a été dédiée ici à ce propos.
Elle est triviale puisque nous choisissons arbitrairement d'ajouter le suffixe _operation au nom d'opération saisi ; par exemple Plus_operation pour l'opération Plus.

Les fonctionnalités du système d'exploitation qui permettront d'arriver à nos fins sont déclarées dans le fichier d'en-tête standard <dlfcn.h>.
Nous y trouvons principalement : Sous Windows, le fichier d'en-tête <dlfcn.h> n'existe pas mais des fonctionnalités équivalents sont déclarées dans <windows.h> ; nous nous contentons ici d'une émulation triviale des fonctionnalités précédentes par un jeu de macros qui fera amplement l'affaire.

Complétez alors la fonction apply_operation() en faisant usage des fonctions précédentes.
Il faudra systématiquement contrôler le succès ou l'échec des appels à dlopen() et dlsym() et produire un message d'erreur explicite le cas échéant.
Pour rappel, les appels data(lib_name) et data(fnct_name) permettent d'obtenir les const char * constitutifs des std::string en question.

Lorsque dlsym() fournira un pointeur non nul, ce dernier sera censé désigner une fonction que nous souhaitons invoquer dans la bibliothèque chargée.
Toutefois, le type void * n'est pas suffisant pour réaliser une telle invocation.
Notre fichier d'en-tête calc.hpp désigne par le nom OperationFunction un type de pointeur de fonction attendant une référence sur un tableau dynamique de réels et renvoyant un booléen.
Les instructions suivantes : convertissent le void * fourni par dlsym() en un pointeur de fonction du type souhaité afin d'invoquer la fonction désignée en lui transmettant le paramètre attendu et en obtenant son résultat.

Fabriquez à nouveau la bibliothèque calc afin de prendre en compte le code que vous venez de rédiger.
Sauf si vous êtes sous Windows, l'édition de liens doit vous indiquer que les fonctionnalités de <dlfcn.h> sont introuvables✍.
Il faut alors intervenir dans le fichier GNUmakefile servant à fabriquer la bibliothèque calc afin de compléter la première occurrence de la variable LDFLAGS que nous trouvons : La bibliothèque standard dl fournit en effet les fonctionnalités en question.

Exécutez le programme prog_calc en saisissant maintenant des noms d'opérations que vous imaginez.
Bien entendu, puisque ces opérateurs n'existent pas encore, des messages d'erreurs explicites doivent signaler l'impossibilité de charger les bibliothèques correspondantes.

Placez vous dans le sous-répertoire CalcQuit qui fournit ce qui nous permettra de réaliser l'opération Quit servant à demander à la calculatrice de se terminer.
En l'état, le fichier de code source CalcQuit.cpp contient déjà la définition de la fonction Quit_operation() qui est conforme à ce que nous espérons invoquer depuis la calculatrice : Son fonctionnement est trivial puisqu'elle se contente d'indiquer par son résultat le fait que la calculatrice doit se terminer.
La fabrication de cette bibliothèque ne doit poser aucun soucis.

En revanche, lorsque vous revenez à l'exécution du programme prog_calc et que vous saisissez la commande Quit vous devez constater un échec d'une nature différente de celle des échec précédents.
Jusqu'alors le chargement de la bibliothèque échouait car elle était simplement introuvable ; désormais, la bibliothèque CalcQuit est bien chargée mais c'est la fonction Quit_operation() qui est introuvable.
Cet échec est dû au fait que nous utilisons la langage C++ pour réaliser cette fonction :

Placez donc la notation extern "C" juste avant le type de retour bool de la fonction Quit_operation().
Après une nouvelle fabrication de la bibliothèque CalcQuit, vous devriez constater que désormais, à la saisie de Quit, la fonction Quit_operation() de cette bibliothèque est bien invoquée, ce qui provoque la terminaison de la calculatrice.

Si vous avez bien compris le principe de ce que vous venez de réaliser, il est désormais possible d'étendre à l'infini le jeux d'opérations de votre calculatrice.
Par exemple, pour ajouter l'opération Plus : Sans arrêter le programme prog_calc qui est en cours fonctionnement dans autre terminal et qui échoue encore à utiliser l'opération Plus, fabriquez la bibliothèque CalcPlus.
Une nouvelle tentative d'invocation de l'opération Plus doit alors aboutir.
Cette nouvelle opération a été rendue accessible sans même devoir arrêter le programme en cours de fonctionnement : voilà qui illustre encore l'aspect dynamique du procédé.

Pour aller plus loin dans cette idée, toujours sans arrêter le programme prog_calc qui est en cours fonctionnement, apportez une modification triviale au code source de l'opération Plus (l'affichage d'un simple message par exemple), refabriquez cette bibliothèque et invoquez à nouveau cette même opération.
Vous devez constater que le changement de comportement de l'opération est perceptible alors que nous n'avons même pas arrêté le programme.
Ce dernier point n'est vrai que parce que nous prenons soin de libérer chaque plugin (avec dlclose()) dès que nous avons fini de nous en servir.
Si vous oubliez volontairement (à l'aide d'un commentaire) l'appel à dlclose() dans calc.cpp et que vous reprenez la même expérimentation✍ vous constaterez qu'une fois chargé, un plugin ne change plus de comportement (les chargements suivants du plugin de même nom sont en quelque sorte ignorés✍).
Bien entendu, cet oubli est une très mauvaise pratique (semblable à l'oubli d'une libération de mémoire ou d'une fermeture de fichier) ; revenez alors à la situation initiale (sans l'oubli de dlclose()).

Si vous souhaitez vous amuser, il ne reste plus qu'à inventer toute une collection d'opérations reposant sur le même principe.
La seule limite est désormais votre imagination.

Le mécanisme de plugins utilisé très artificiellement dans l'application précédente est très communément utilisé pour étendre des langages d'assez haut niveau (Python, Tcl, Java, JavaScript, C#...) afin de leur fournir des fonctionnalités réalisées très efficacement en C, C++, Rust...
Nous nous proposons de découvrir ici un moyen simple d'étendre le langage Python par des fonctions réalisées en C/C++✍ : le module ctypes.

Nous travaillerons dans le répertoire PythonPlugin.
Le fichier native.cpp est déjà rédigé ; il contient des fonctions simplistes utilisant la notation extern "C" afin d'être retrouvées facilement dans la bibliothèque dynamique Native qui sera fabriquée par la commande make.
Il s'agit ici de compléter le programme Python use_native.py pour qu'il fasse usage des fonctions de cette bibliothèque.

Remarquez tout d'abord que la fonction main() utilise la fonction ctypes.CDLL() pour charger la bibliothèque dynamique en question✍ depuis le répertoire courant.
Complétez alors la fonction step_01() afin qu'elle recherche dans cette bibliothèque la fonction minimal().
Il suffit pour cela d'invoquer [] sur la bibliothèque en indiquant le nom de la fonction recherchée sous la forme d'une chaîne de caractères.
Le résultat de cette recherche s'utilise ensuite comme s'il s'agissait d'une simple fonction ; vous devriez alors constater l'affichage produit par la fonction minimal() en C++.

L'invocation de la fonction minimal était triviale dans la mesure au aucun paramètre n'était à fournir et aucun résultat n'était attendu.
En complétant la fonction step_02() nous allons cette fois-ci chercher à invoquer la fonction simple_types(), ce qui conduira à échanger des valeurs ayant des types simples entre Python et C/C++.
La fonction obtenue en Python depuis la bibliothèque dispose de propriétés permettant de préciser le prototype de cette même fonction du côté C/C++.
La propriété restype de cet objet Python devra être initialisée à ctypes.c_double afin de préciser le type de retour.
De la même façon, la propriété argtypes de cet objet Python devra être initialisée par le triplet [ctypes.c_int, ctypes.c_float, ctypes.c_char_p] afin de décrire les trois paramètres attendu.
Consultez la documentation de ctypes afin de prendre connaissance des types disponibles à cet effet.
Il ne reste plus qu'à invoquer cette fonction en fournissant des paramètres ayant les types attendus✍ et en récupérant son résultat afin de l'afficher.
Les affichages provoqués en C++ et en Python doivent témoigner de la bonne transmissions de toutes ces données.

Un autre besoin assez fréquent consiste à offrir au code C/C++ la possibilité de modifier des données déjà existantes dans le programme Python.
La démarche classique en C/C++ consiste à utiliser des paramètres passés par adresse (pointeurs en C, références en C++) et c'est ce que fait la fonction references() de notre exemple en C++.
Complétez alors la fonction step_03() pour rendre une telle invocation possible.
La fonction references recherchée dans la bibliothèque n'aura pas de propriété restype (ou alors None) mais précisera comme propriété argtypes la paire [ctypes.c_void_p, ctypes.c_void_p] afin de décrire les deux paramètres attendu.
Remarquez que nous les indiquons comme de simples pointeurs sur un type quelconque(void * du langage C) ; c'est à nous d'être cohérent en fournissant effectivement des pointeurs qui désignent bien des données des types attendus.
Le premier paramètre attendu du côté C++ est une référence vers un entier et le second est une référence vers un réel✍.
Nous devons donc créer du côté Python un entier et un réel qui soient semblables à ce qui est connu de C/C++ afin d'en passer l'adresse.
Les écritures a=ctypes.c_int(10) et b=ctypes.c_double(20.25) créent justement de telles données avec des valeurs choisies : utilisez leur propriété value pour afficher les valeurs mémorisées.
Le passage de paramètre à la fonction invoquée utilisera les notations ctypes.byref(a) et ctypes.byref(b) afin d'en transmettre les adresses et non les valeurs.
Contrôlez alors, par des affichages après l'invocation de references(), que ces deux variables ont bien les nouvelles valeurs attendues.

Le choix de recourir à du code C/C++ depuis Python est très souvent motivé par la nécessité de réaliser de nombreux calculs de manière très efficace ; les bibliothèques Python très en vogue reposent essentiellement sur ce principe pour traiter de gros volumes de données (calcul numérique, traitement d'images, apprentissage automatique...).
Il s'agit donc de préparer des tableaux contenant la multitude d'informations utiles du côté Python tout en offrant la possibilité au code C/C++ de travailler directement sur les données mémorisées dans ces tableaux.
En complétant la fonction step_04(), nous invoquerons la fonction access_array() de la bibliothèque dynamique ; renseignez alors les propriétés restype et argtypes pour respecter le prototype de cette fonction.
Il nous faut alors créer du côté Python un tableau de réels qui soit directement exploitable par le code C/C++ ; cette écriture array=(ctypes.c_double*5)() crée justement un tableau de 5 réels contigus✍.
Attribuez des valeurs quelconques aux éléments de ce tableau et affichez son contenu, en utilisant le résultat de show_array(), avant d'invoquer la fonction access_array().
Affichez ensuite le résultat de cette invocation et le nouveau contenu du tableau afin de constater que le code C++ en a bien fait usage (les éléments ont été triés et leur somme est renvoyée).

La fonction step_05() est déjà complète car il serait difficile d'en décrire tous les détails sans les écrire entièrement ; il suffira d'en étudier le code et le comportement.
Elle illustre la situation où le code C/C++ prend beaucoup plus d'initiatives que le simple accès à des données préparées depuis Python.
La fonction create_Something() crée un objet assez élaboré, bien que complètement fantaisiste dans cet exemple, du coté C++ et le renvoie à Python sous la forme d'un simple pointeur.
Bien entendu, le code Python ne peut rien en faire directement mais se contente de retransmettre ce pointeur lors des invocations de code C/C++ ultérieures afin que cet objet élaboré créé précédemment soit à nouveau exploité.
La fonction use_Something() illustre ici le fait que des données créées entièrement du côté C++ (une std::string et un std::vector ici) peuvent être rendues accessibles au code Python.
Remarquez en particulier ce point très important : le tableau values obtenu en Python n'effectue pas une potentiellement coûteuse recopie des données possédées par le std::vector mais se contente de les référencer directement là où elles sont déjà en mémoire✍.
Enfin, lorsque le code Python estime qu'il n'aura plus à faire usage de cet objet C++ élaboré, il le signifie au code C++ (par la fonction destroy_Something() ici) afin que cet objet soit détruit dans les conditions habituelles de ce langage.

Cette découverte d'un moyen simple de faire interagir Python et C/C++ ne visait qu'à mettre en évidence les principes élémentaires sous-jacents.
Pour réaliser des traitements plus significatifs, veuillez vous reporter aux exercices App_01 et App_02 du cours de langage C ainsi qu'aux exercices App_01 et App_02 du cours de langage C++ moderne.