Discussion :

[Artemus24]

Salut à tous.

Quel est la différence à l'usage entre une bibliothèque dynamique et une bibliothèque d'importation !
Je parle aussi bien du 'C' que du 'C++'.
Je trouve que l'usage de la bibliothèque d'importation est très proche de celle de la bibliothèque statique.
Quand à la bibliothèque dynamique, je trouve cela plutôt lourd pour un usage non pertinent.

Peut on me donner un exemple d'usage où la bibliothèque dynamique serait mieux que la bibliothèque d'importation ?

[gerald3d]

Bonjour.

Si tu poses la question c'est que je suppose que tu es sous Windows (le "problème" n'existe pas sous linux).

La vraie différence se situe entre bibliothèque dynamique et statique :

• dynamique : le code exécutable de la bibliothèque est chargée lors de l'exécution de l'application ;
• statique : le code d'exécution de la bibliothèque est intégrée au code de l'exécutable (fichier .exe beaucoup plus gros)

Lorsque tu cites dynamique et d'importation dans les faits ils sont liés :

• importation : .lib sert au compilateur pour lier les fonctions de la bibliothèque à l'application (il utilise aussi le .h) ;
• dynamique : .dll code d'exécution de la bibliothèque chargée lors du lancement de l'application.

[foetus]

Comme le dit @gerald3d, la bibliothèque statique est rajoutée dans l'exécutable.
Cela fait des exécutables + gros, mais + portables parce que tu n'as pas dépendances (du moins - de dépendances)

L'autre différence (qui est lié à l'exécution d'un exécutable), avec une bibliothèque dynamique, lorsque tu appelles une fonction dedans, le système d'exploitation va regarder si cette fonction est en mémoire, sinon la charge, et l'appelle.
Donc il ne va charger que les parties que tu as besoin et non l'intégralité de ta bibliothèque.

[Artemus24]

Salut à tous.

Merci pour vos réponses.

@ Gerald3d : oui, je suis sous windows 10 Pro.
Sauf que vous m'expliquez comment cela fonctionne alors que je cherche à savoir dans quel cas, fait on l'usage de tel ou tel bibliothèque.
Je ne m'intéresse pas ici à la bibliothèque statique.
Je cherche à comprendre dans quel cas va-t-on privilégier la bibliothèque d'importation par rapport à la bibliothèque dynamique.
Je trouve que la bibliothèque dynamique est lourde à l'usage et je ne comprends pas trop dans quel cas l'utiliser.
Inversement, je trouve que la bibliothèque d'importation est plus souple à l'usage et plus simple à développer.

Pouvez vous me donner un usage pour chacune de ces deux bibliothèque ?
Je suppose que s'il ces bibliothèques existent, il y a un besoin réel, non ?

[gerald3d]

Effectivement je n'ai pas vraiment répondu à la question, du moins en toute petite partie. @foetus apporte un début de réponse.

Si j'ai donné l'explication de qui fait quoi c'est simplement parce que j'ai l'impression, ou c'est moi qui suis totalement à côté, que tu utilises des termes qui veulent dire la même chose. Bibliothèque dynamique et d'importation sont pour moi la même chose. Si tu utilises une bibliothèque d'importation c'est qu'en réalité tu utilises forcément une bibliothèque dynamique. La bibliothèque d'importation est utilisée lors du "linkage" du compilateur avec une bibliothèque dynamique.

Donc, en résumé il n'y a que deux types de bibliothèque :

1. dynamique : l'exécutable doit être accompagné des fichiers des bibliothèques utilisées ;
2. statique : tout le code est contenu dans l'exécutable.

Maintenant dans quel cas utiliser l'une ou l'autre ?

Ce n'est pas forcément évident de répondre à cette question mais je vais essayer de donner un exemple pour chacune :

• statique : une application de type zip qui est capable de compacter des données et de générer en même temps un exécutable. L'utilisateur final n'a pas besoin d'installer les outils nécessaires. L'exécutable intègre tous les outils de décompactage ainsi que les données à traiter ;
• dynamique : un bon exemple est les jeux vidéos. Ils installent dans un répertoire personnel les bibliothèques qui pourtant existent déjà sur le système. Mais ils installent une version adaptée à leur fonctionnement. Ceci évite les conflits liés à la version du système d'exploitation et assure que l'application fonctionnera à peu prés sur toutes les machines. Si je prends mon cas je programme sous linux avec Gtk. Si je devais porter mon application sous Windows je devrais forcément installer Gtk sous cet environnement, ce qui n'est pas à priori facile. Comme Gtk est relativement imposant je ne me vois pas l'intégrer en statique.

[Guesset]

Bonjour,

Les DLL offrent des possibilités que n'offrent pas les bibliothèques statiques :

• Tant que les fonctions gardent les mêmes caractéristiques, elles peuvent évoluer (corrections, accélérations...) sans retoucher à l'application principale.
• Elles sont partageables par plusieurs applications sans nécessiter leurs démultiplications : par exemple, les pilotes.
• Elles peuvent être chargées en différé (même si la très grande majorité des applications le fait au démarrage) : par exemple, ne charger que la version optimisée pour le processeur et l'environnement d'exécution.
• Elles peuvent partager une interface commune définie par l'application pour offrir des fonctions différentes : par exemple les plugins de GIMP et autres...

En revanche, l'appel des fonctions des DLL subit une indirection de plus que la même fonction intégrée. Ce n'est donc pas indiqué pour des micro-fonctions.
Si on vise la réutilisation possible, la conception des DLL est plus complexe, ne serait-ce que parce que la DLL ne peut alors présupposer l'environnement applicatif qui l'appelle. Par exemple, la qualité des arguments passés à ses fonctions doit être contrôlée alors que l'appelant l'a peut-être déjà fait.

Salutations

[foetus]

Bibliothèque dynamique et d'importation sont pour moi la même chose. Si tu utilises une bibliothèque d'importation c'est qu'en réalité tu utilises forcément une bibliothèque dynamique

MSDN précise que les bibliothèques d'importation c'est l'outil LIB.exe : LIB Reference en anglais

LIB (lib.exe) creates standard libraries, import libraries, and export files you can use with LINK when building a program. (dans la section overview of LIB/ vue d'ensemble de LIB)

bibliothèque d'importation est la traduction de "import library" que l'on peut lire en français en changeant le en-us du lien MSDN par fr-fr

Donc, en résumé il n'y a que deux types de bibliothèque

Techniquement il y a 3 types de bibliothèque sous Windows : 3) "shared libraries"
Je suis rouillé sur cette notion et Google/ IA doit l'expliquer précisément mais tu linkes statiquement la liste des fonctions/ objets d'une bibliothèque dynamique (.dll) : tu gardes l'aspect statique pour ton exécutable et en même temps, tu as une .dll que tu peux partager/ modifier.

[Artemus24]

Bibliothèque dynamique et d'importation sont pour moi la même chose.

Pas du tout, sinon je n'aurai pas ouvert ce sujet.
J'en conviens que la différence peut venir du vocabulaire mais dans les faits, ce n'est pas la même chose, surtout au niveau du makefile.

Prenons le cas d'une bibliothèque de nom "test".
La bibliothèque statique se nomme "libtest.a". Dans le makefile, on indique le chemin où elle se trouve et à l'édition des liens, on précise "-ltest".
la bibliothèque dynamique se nomme "test.dll". On ne fait aucune référence à cette bibliothèque dans le makefile, mais à l'exécution, on doit préciser dans le chemin (PATH) où elle se trouve.
la bibliothèque d'importation se nomme "test.dll". Il y a aussi "libtest.dll.a" ainsi que "-ltest" pour l'édition des liens. On précise à l'exécution le chemin où elle se trouve, comme dans le cas de la bibliothèque dynamique.

La bibliothèque d'importation est très similaire à la bibliothèque statique pour l'édition des liens, avec en plus à l'exécution, le chemin (PATH) où elle se trouve. Pour le développement, c'est quasiment pareil. Je ne vois que des avantages à son utilisation.
Voilà de ce que j'ai compris, mais le problème n'est pas là.

Il me semble que la bibliothèque dynamique est plus fait pour du développement Windows Win32, pas pour de la console.
Elle utilise les fonctions "loadLibray()" pour accéder à la bibliothèque et "GetProcAddress()" pour accéder à chaque fonction.
Sans compter les problèmes du passage des arguments qui peuvent différer.
Je trouve cela lourd et compliqué à mettre en œuvre quand tu as plusieurs fonctions gérées de cette façon là.

D'accord dans l'usage des jeux. Mais est-ce dynamique ou d'importation ? Je suppose dynamique.
Ce qui me surprend, il existe déjà des bibliothèques dynamiques dans le répertoire Windows, que l'on peut venir écraser par une nouvelle version pour des applications qui en font l'usage, sans que cela vienne perturber Windows qui en à aussi l'usage.

@ Guesset : ce que tu décris est bien la lourdeur des bibliothèques dynamiques qui s'utilisent dans un environnement Windows, à moins de me tromper à ce sujet.

@ foetus : je crois que shared library est synonyme de dynamic library.
Il y a donc bien trois types de bibliothèques : statique, dynamique et d'importation.

Est-ce que je me trompe, mais il me semble que vous ne connaissez pas les bibliothèques d'importations ?

[gerald3d]

Au temps pour moi. Je ne connaissais pas cette subtilité entre importation et dynamique.

Comme quoi on en apprend tous les jours .

[Obsidian]

Salut à tous,

Cela fait très longtemps que je n'avais plus remis les doigts dans la programmation Windows au niveau du C/C++ (la dernière fois, ça devait être en 2002 avec la C.API et les MFC sous Visual Studio) mais de ce que je m'en souviens et ce que j'en trouve quand je fais une recherche, il semble que :

• Les DLL sont bien les bibliothèques dynamiques sous Windows (et les même les versions récentes de DOS mais je dis ça de mémoire et j'ai peur de dire une ânerie), homologues des bibliothèques partagées sous (shared library sous Unix). Ça c'est OK pour tout le monde ;
• Les LIB sont bien les bibliothèques statiques sous Windows, et pour le coup utilisent le même format *.a que les bibliothèques statiques Unix (en fait, OMF ou COFF selon les versions, générés avec ar mais pas sur les mêmes plateformes) ;
• Les fichiers d'import sont en fait le manifeste de ce que contient une DLL (les symboles et leur points d'entrée dans le fichier) et sont nécessaires au linker parce que, pour une raison qui reste à déterminer, il n'est pas capable d'aller directement explorer la DLL concernée pour le savoir, ce qui est une spécificité du monde Windows.

Et la clé du mystère en bonus :

• Ce manifeste est une ressource qui est elle-même distribuée sous forme de bibliothèque statique, ce qui explique pourquoi le fichier porte la même extension et respecte le même format.

Donc, quand on produit une DLL, le compilateur va générer à la fois le fichier DLL et le fichier LIB qui l'accompagne, mais ce fichier LIB n'est pas la version statique de la bibliothèque. Juste le fichier d'import (le manifeste en question). Ce fichier d'import, à son tour, n'est nécessaire que pour compiler un exécutable s'appuyant sur une (ou plusieurs) DLL. Une fois produit, le fichier d'import n'est plus nécessaire.

Pourquoi cette particularité ? Je l'ignore mais on peut envisager beaucoup de raison à ça :

— La première est que la DLL proprement dite peut être très grosse et qu'il n'était pas forcément pertinent de se la trimbaler en entier dans un projet tiers si c'est uniquement pour permettre à la compilation d'aller jusqu'à son terme.
— La deuxième est que bien souvent, ces DLL étaient commerciales et qu'il coûtait cher de les acquérir et que distribuer l'interface seule était une solution qui arrangeait à la fois la société éditrice de la lib et celle qui en avait besoin pour compiler.
— La troisième est que tous les systèmes d'exploitation n'utilisent pas forcément d'interruption ou d'instruction dédiée pour déclencher des appels système. Il se peut alors que ces appels systèmes du noyau respectent la même ABI et les mêmes conventions d'appel. Dans cette situation, un même fichier d'import est nécessaire pour les invoquer mais eux ne font pas l'objet d'un fichier DLL dédié.

[Médinoc]

La bibliothèque d'importation est un intermédiaire entre ton code et une bibliothèque dynamique. Un intermédiaire qui fait tout le boulot pour toi, mais seulement pour le cas d'utilisation le plus courant: Celui où tu as besoin de la bibliothèque dynamique du même nom, toujours la même, durant toute l'exécution du programme.

C'est pour les autres cas qu'il convient de charger manuellement les bibliothèques dynamiques. Quand tu ne sais pas à l'avance de quelle bibliothèque dynamique tu vas avoir besoin. Pour un lot de plug-ins, par exemple. Ou pour pouvoir décharger la bibliothèque dynamique après usage. Le genre de trucs qui est facilité par des bibliothèques dynamiques respectant des conventions précises, par exemple les composants COM.

[foetus]

Donc, quand on produit une DLL, le compilateur va générer à la fois le fichier DLL et le fichier LIB qui l'accompagne, mais ce fichier LIB n'est pas la version statique de la bibliothèque. Juste le fichier d'import (le manifeste en question). Ce fichier d'import, à son tour, n'est nécessaire que pour compiler un exécutable s'appuyant sur une (ou plusieurs) DLL. Une fois produit, le fichier d'import n'est plus nécessaire

Comme je le disais avant (mais à vérifier parce que je suis rouillé sur le sujet ) c'est ce manifeste qui est la différence

1) bibliothèque dynamique : tu ignores ou tu ne crées pas ce manifeste, mais tu as une .dll. C'est la programmation classique avec LoadLibrary/ FindResource/ FreeLibrary/ ... (<- **)
2) "shared library" : tu linkes statiquement ton exécutable avec ce manifeste mais pas avec la .dll. Donc tu programmes comme "en static" (tu accèdes directement à ta DLL sans la surcouche **). Mais tu es obligé d'avoir l'exécutable + DLL pour que ton exécutable fonctionne.

Par contre bibliothèque d'importation ("import library") je ne me prononce pas sur qu'est que c'est. En lisant le MSDN LIB Reference, ce n'est pas clair

Le seul truc sûr, ce sont tout ce qui existe depuis au moins 25 ans : .lib/ .a, .dll/ .so, le manifeste, static/ dynamic/ shared (Windows seulement)

[Artemus24]

Ça c'est OK pour tout le monde ;

Je suis d'accord.

Les LIB sont bien les bibliothèques statiques sous Windows

Pour les bibliothèques statiques, c'est "libtest.a", test étant le nom de la bibliothèque.
Quand à la bibliothèque d'importation, c'est plutôt : "libtest.dll.a", toujours avec "test comme nom.

D'ailleurs, dans "C:\Msys64\ucrt64\lib" sous Windows, je ne vois que des bibliothèques se terminant par :
".o", je suppose des objets.
".a" pour les bibliothèques statiques.
"ddl.a" pour les bibliothèques d'importations (il y en a très peu).
Mais pas de ".lib". En fait, je ne connais pas ce suffixe.
On trouve cela, peut-être, sous MSVC, mais ce ne sont pas des bibliothèques statiques.
Pourquoi ? Car elles sont accompagnés d'une ".dll".

Les fichiers d'import sont en fait le manifeste de ce que contient une DLL

Je suis d'accord.

Le manifest en question ("test.dll.a") ne contient aucune fonctions. Elles sont toutes dans "test.dll".
Par contre, si tu ajoutes une nouvelle fonction, tu devras refaire une édition des liens du programme qui utilise ce manifest.
alors que si tu viens à simplement modifier une fonction déjà existante, tu n'es pas obligé de refaire une édition des liens.

La deuxième est que bien souvent, ces DLL étaient commerciales

Je n'avais pas pensé au fait que ces bibliothèques peuvent être, comme tu dis, commerciale.
D'où l'intérêt de les externaliser et non de les inclures dans un programme.
Surtout si cette bibliothèque est utilisée à plusieurs reprises dans différents programmes.

La troisième est que tous les systèmes d'exploitation n'utilisent pas forcément d'interruption ou d'instruction dédiée pour déclencher des appels système.

Désolé, mais je ne sais pas de quoi tu parles.

Quand tu ne sais pas à l'avance de quelle bibliothèque dynamique tu vas avoir besoin.

C'est un usage que je ne connais pas. Choisir sa bibliothèque au moment du traitement ??? Bizarre comme façon de faire.
En tout cas, je n'en ai pas l'usage.

@ Foetus : une "shared library" sous linux est l'équivalent d'une "dynamic library" sous windows.
Sous linux, c'est fichier se terminant par ".so", alors que sous windows, c'est ".dll".

Je pense qu'au niveau vocabulaire, quand on parle de bibliothèque d'importation, on fait référence à ".dll.a".
Et non à la bibliothèque dynamique, qui est la ".dll". Sous linux, ce la se nomme la bibliothèque partagée (shared library).

L'équivalent des fonctions windows sous linux sont :
"loadlibrary()" : "dlopen()".
"GetProcAddress()" : "dlsym()".
"FreeLibrary()" : "dlclose()".
"GetLastError()" : "dlerror()".
Sinon, c'est le même la mécanisme entre windows et linux.

C'est ce que j'ai compris.

[Christophe]

Pourquoi cette particularité ? Je l'ignore

Moi aussi, mais ça pourrait pas être du au format utilisé sous Windows pour stocker le code objet ? (ex: COFF vs ELF)

[gerald3d]

Tu me prêtes des écrits qui ne sont pas les miens mais ce n'est pas bien grave . L'important est que ces discussions fassent avancer les connaissances de chacun .

Je suis d'accord.


Pour les bibliothèques statiques, c'est "libtest.a", test étant le nom de la bibliothèque.
Quand à la bibliothèque d'importation, c'est plutôt : "libtest.dll.a", toujours avec "test comme nom.

D'ailleurs, dans "C:\Msys64\ucrt64\lib" sous Windows, je ne vois que des bibliothèques se terminant par :
".o", je suppose des objets.
".a" pour les bibliothèques statiques.
"ddl.a" pour les bibliothèques d'importations (il y en a très peu).
Mais pas de ".lib". En fait, je ne connais pas ce suffixe.
On trouve cela, peut-être, sous MSVC, mais ce ne sont pas des bibliothèques statiques.
Pourquoi ? Car elles sont accompagnés d'une ".dll".


Je suis d'accord.

Le manifest en question ("test.dll.a") ne contient aucune fonctions. Elles sont toutes dans "test.dll".
Par contre, si tu ajoutes une nouvelle fonction, tu devras refaire une édition des liens du programme qui utilise ce manifest.
alors que si tu viens à simplement modifier une fonction déjà existante, tu n'es pas obligé de refaire une édition des liens.


Je n'avais pas pensé au fait que ces bibliothèques peuvent être, comme tu dis, commerciale.
D'où l'intérêt de les externaliser et non de les inclures dans un programme.
Surtout si cette bibliothèque est utilisée à plusieurs reprises dans différents programmes.


Désolé, mais je ne sais pas de quoi tu parles.


C'est un usage que je ne connais pas. Choisir sa bibliothèque au moment du traitement ??? Bizarre comme façon de faire.
En tout cas, je n'en ai pas l'usage.

@ Foetus : une "shared library" sous linux est l'équivalent d'une "dynamic library" sous windows.
Sous linux, c'est fichier se terminant par ".so", alors que sous windows, c'est ".dll".

Je pense qu'au niveau vocabulaire, quand on parle de bibliothèque d'importation, on fait référence à ".dll.a".
Et non à la bibliothèque dynamique, qui est la ".dll". Sous linux, ce la se nomme la bibliothèque partagée (shared library).

L'équivalent des fonctions windows sous linux sont :
"loadlibrary()" : "dlopen()".
"GetProcAddress()" : "dlsym()".
"FreeLibrary()" : "dlclose()".
"GetLastError()" : "dlerror()".
Sinon, c'est le même la mécanisme entre windows et linux.

C'est ce que j'ai compris.

[Médinoc]

JMais pas de ".lib". En fait, je ne connais pas ce suffixe.
On trouve cela, peut-être, sous MSVC, mais ce ne sont pas des bibliothèques statiques.
Pourquoi ? Car elles sont accompagnés d'une ".dll".

Les bibliothèques d'importation sont un type particulier de bibliothèques statiques. C'est pour ça que dans MSYS, les deux ont des noms qui finissent par "-.a" (d'ailleurs, le "-.dll-" intercalaire n'était pas là dans les années 2000). Et c'est pour ça que MSVC utilise ".lib" pour les deux.

C'est un usage que je ne connais pas. Choisir sa bibliothèque au moment du traitement ??? Bizarre comme façon de faire.
En tout cas, je n'en ai pas l'usage.

C'est utilisé par exemple dans les lecteurs multimédia, où ajouter de nouveaux codecs consiste à ajouter de nouvelles DLL, ainsi que la configuration indiquant au programme lecteur dans quelle DLL se trouve le codec pour tel ou tel format.
Vu que tu n'en as pas l'usage, le plus simple pour toi est de lier simplement ton programme à la bibliothèque statique d'importation, et la bibliothèque dynamique sera liée pour toi sans que tu aies à te soucier de ce qui se passe sous le capot.

[foetus]

Mais pas de ".lib". En fait, je ne connais pas ce suffixe.
On trouve cela, peut-être, sous MSVC, mais ce ne sont pas des bibliothèques statiques.
Pourquoi ? Car elles sont accompagnés d'une ".dll"

D'accord cela ne s'appelle pas *shared library*, c'est peut-être un vieux terme ou je-ne-sais-quoi

Mais lorsque tu utilises 1 .dll sous Windows, tu as bien 2 types d'édition de liens : l'explicite et l'implicite.
Et dans la méthode implicite, tu as bien un .lib qui doit être le manifeste.

Link an executable to a DLL, MSDN en anglais

[Guesset]

Bonjour,

Pour pouvoir appeler les fonctions d'une DLL (dont on n'a pas les sources en général), il faut un fichier d'en-tête qui décrive les noms et chemins aux fonctions de la DLL et éventuellement quelques constantes et structures. Des noms d'usages qu'utilisera l'application sont également présents. En général, ils s'inspirent des noms internes à la DLL, mais ce n'est pas une obligation.

Pourquoi les fonctions (noms et signatures) ne sont pas découvertes automatiquement ? Il y a plusieurs raisons :

• Toutes les fonctions d'une DLL n'ont pas nécessairement vocation à être exportées.
• Les noms ainsi récupérés peuvent être inutilisables pratiquement si les sources de la DLL ont été brouillés (par exemple, dans un souci de préservation pour une DLL commerciale)
• Comment une application pourrait anticiper l'usage de fonctions qu'elle ne découvrirait qu'à l'exécution ?

Ce .h ou .hpp est associé à un .c ou .cpp généralement vide. Ils font partie de l'application et servent de pont vers la ou les DLL qui partagent les même jeux de fonctions décrites.

Ne connaissant pas bien le monde UNIX, ceci n'est valable, sauf erreurs , que pour Windows.

Salutations

[Artemus24]

Et dans la méthode implicite, tu as bien un .lib qui doit être le manifeste.

Avec la bibliothèque d'importation sous Windows, j'ai bien un ".dll", mais aussi un ".dll.a", mais pas de ".lib".
Je suppose que le ".lib" est en fait le ".dll.a", ce que Gerald3d nomme le manifest.
C'est au démarrage de l'exécution que la ".dll" est chargé. Si j'ai bien compris, cela se nomme "liaison implicte".
Aucune référence à "LoadLibrary()" ou "GetProcAddress()".

Avec la bibliothèque dynamique, lors de l'édition des liens, le programme ne connait pas la ".dll".
C'est durant l'exécution du programme que sera décidé quoi prendre comme ".ddl".
D'où le fait d'utiliser "LoadLibrary()" ou "GetProcAddress()". Je pense que c'est cela la "liaison explicite".

Dans les deux cas, la ".dll" est séparée du programme. D'où à l'exécution de préciser où se trouve cette ".dll" en ajoutant le répertoire dans le "PATH".

@ Guesset : dans le cas des bibliothèques dynamiques, il n'est pas nécessaire d'avoir le header (.h ou .hpp").
Il est conseillé d'avoir ce header pour les bibliothèques statiques et d'importations.
Chacun fait comme il veut sa gestion des sources et des headers.

[Guesset]

Bonjour,

Doc MS (https://learn.microsoft.com/fr-fr/tr...c-link-library) pour le chargement de DLL au démarrage : "Pour utiliser la liaison dynamique au moment du chargement, fournissez un fichier d’en-tête (.h) et un fichier de bibliothèque d’importation (.lib) lorsque vous compilez et liez l’application... Dans la liaison dynamique au moment du chargement, vous devez lier la bibliothèque d’importation SampleDLL.lib qui est créée lors de la génération du projet SampleDLL."

Pour un chargement différé (et éventuellement une libération anticipée), l'association se fait fonction par fonction. La souplesse se paye donc par une écriture sensiblement plus lourde.

Il y a beaucoup d'applications où le démarrage voit défiler une ribambelle de dll dont très peu seront utilisées. Le choix de la simplicité se traduit donc par un démarrage lent.

Salutations