Discussion :

[tintin72]

Bonjour,

Ma question est plutôt d'ordre général, et je m'excuse par avance si elle est maladroite .
Je m'initie à la prog (en C++ sous Windows) et j'en suis au stade de l'écriture de dll.
Toutefois, j'ai trouvé trés peu de docs ou de tutos traitant de l'écriture de dll en C++.
D'ailleurs c'est plutôt compliqué (en gros il faut "wrapper" les fonctions de la dll) et les auteurs des tutos
concluent souvent en disant qu'à moins d'en avoir une véritable utilité il vaut mieux écrire les dll en C.

Donc, puisque le moindre logiciel un peu évolué utilise obligatoirement des dll et que celles-ci
sont apparement écrite en C, qu'en est il du "tout objet" ?
En effet, j'entend partout parler de C++ et de POO à tous les étages mais qu'en est-il réellement ?
Est-il possible d'écrire un logiciel où tout le code serait OO de A à Z ou est-on forcément obligé de composer
avec le C ?

Merci de m'éclairer

[loufoque]

Le système de DLL n'a absolument rien à voir avec C++, c'est très lié à l'API Win32.
D'autres systèmes d'exploitation que Windows ont d'ailleurs d'autres solutions, voire pas de solution du tout.

Quoiqu'il en soit, l'usage de bibliothèques dynamiques n'est pas vraiment indispensable d'autant plus que faire cela sans sacrifier la portabilité n'est pas nécessairement pratique.

[Alp]

Pour continuer dans la direction de loufoque:
- Utiliser des librairies dynamiques force à compiler ces lib pour chaque plateforme pouvant faire tourner le logiciel.
- C'est bien pour éviter de recompiler, pour les maj et tout oui, mais bien des logiciels savent s'en sortir autrement.

En gros, les librairies dynamiques ca peut aussi faire perdre du temps selon les ambitions du programme niveau plateformes, maj, modularité...

[JolyLoic]

En plus du fait que les DLL ne sont pas nécessaires, il est possible fe faire des DLL qui exportent des objets. Le plus simple que j'ai trouvé est d'avoir par exemple une classe de base toute virtuelle, inclue dans la DLL et dans le programme principal, et dans la DLL un eclasse qui dérive de la première et l'implémente. Cette DLL fourni aussi, en C, une fonction de factory retournant un pointeur sur la classe de base. Et hop, le tour est joué. A condition que DLL et programme principal soient développés par le même compilateur avec les mêmes options.

Pourquoi les DLL ne sont pas plus POO-friendly ? Probablement parce que les langages objets tels que C++ laissent une grande latitude en matière d'implémentation, ce qui fait qu'il n'y a pas une façon de faire standard, ce qui est un frein pour l'interopérabilité entre programmes. D'autres langages, par exemple les langages .NET, imposent plus de choses de ce point de vue, et permettent des "DLL" (bien qu'ayant le nom, elles sont incompatibles) plus "objet".

[Luc Hermitte]

Comme signalé, les DLL n'ont pas de rapport direct avec le C++. Il s'agit d'une forme de bibliothèques dynamiques.

Pourquoi le conseil de rester au niveau du C? Il faut savoir qu'il n'existe pas d'ABI (Application Binary Interface) pour le C++ [1]. Cela veut dire qu'une bibliothèque C++ compilée avec un compilateur ne sera pas nécessairement utilisable avec un autre compilateur C++ [2]. La seule compatibilité possible se fait au niveau du C.



[1] En fait, il en existe qu'une pour une seule plateforme à ma connaissance, et ce n'est pas windows.
[2] Et pour simplifier les choses, les tables de compatibilités ne sont pas symétriques -- "tables" au pluriel car il y a des différences entre les bibliothèques statiques et les bibliothèques dynamiques. Les curieux pourront les trouver dans Imperfect C++ de Matthew Wilson, chez Addisson-Wesley (comme d'hab). Il a tout un chapitre sur le sujet. Et des gros hacks qui tâchent pour faire des bibliothèques OO "portables" et utilisable depuis le C ou le C++.

Edit: Dernier truc. Le C++ est un langage pragmatique. Se limiter à l'OO, c'est ignorer une bonne parti de la puissance du langage.

[tintin72]

Merci pour vos réponses, j'y vois un peu plus clair maintenant

Le système de DLL n'a absolument rien à voir avec C++, c'est très lié à l'API Win32.

oui, oui je sais , l'équivalent sous linux sont les fichiers *.so je crois, mais je connais mal cet environnement et je ne sais pas si ces fichiers peuvent être écrit en C++.

Quoiqu'il en soit, l'usage de bibliothèques dynamiques n'est pas vraiment indispensable

bien des logiciels savent s'en sortir autrement

Ok, mais qu'y a t-il alors comme alternative aux librairies dynamiques (à part les librairies statiques) ?

[loufoque]

Tout d'abord, pourquoi cherches-tu à utiliser des bibliothèques dynamiques ? Pour permettre à l'utilisateur de mettre à jour la bibliothèque (obligatoire avec les bibliothèques sous licence LGPL) sans recompiler l'application dont tu ne veux pas distribuer les sources ? Cela peut se faire simplement en fournissant les fichiers objet.

Après, ça permet en effet d'éviter d'avoir plusieurs fois le même code sur une machine puisqu'il suffit d'avoir une seule fois la bibliothèque.

[tintin72]

Tout d'abord, pourquoi cherches-tu à utiliser des bibliothèques dynamiques ?

Déjà pour alléger l'application (pour pas me retrouver avec un .exe énorme). Ensuite je trouve que c'est mieux de dispatcher le code dans différentes dll, ça donne une vision plus globale de l'ensemble et ça permet de corriger/modifier plus facilement le code (on recompile juste la dll).
C'est pour ça que je voulais savoir s'il y avait une alternative aux dll.

[loufoque]

ça permet de corriger/modifier plus facilement le code (on recompile juste la dll).

C'est pareil sans...

[Médinoc]

Ben non: Pour une lib statique par exemple, il faut recompiler tous les programmes qui l'utilisent...

Pour un exe, il faut recompiler tout l'exe, livrer tout l'exe quand il y a une modification, etc.

[loufoque]

Il n'y a recompiler que les fichiers qui ont été modifiés.
Après on lie avec les fichiers objet obtenus précedemment

[dabeuliou]

Il y a un cas qui n'a pas été cité mais qui me semble nécessiter l'utilisation de dll : les plugins d'une application.
J'en arrive à cette conclusion en suivant le raisonnement suivant (huez-moi si je me trompe...) :

- un plugin d'une appli ne peut être que sous forme d'une dll (si y a un exe, faudra me dire où est le côté plugin, hein...)
- comme il étend les fonctionnalités d'une appli, il doit connaître au moins une partie de cette appli et doit être linké avec au moins une partie de l'appli.
- on ne peut linker une dll que avec d'autres dll, pas avec un exe
=> le code de l'appli qui est réutilisé par les plugins doit être exporté dans une dll.

Au passage, si les plugins et l'appli sont développés dans le même langage (C++, mettons), je ne vois pas pourquoi toutes les dll ne pourraient pas être codées en C++ (sans wrapper avec du C, donc).

Je me trompe peut-être, je suis intéressé d'avoir votre avis

[Graffito]

Bonjour,

Ok, mais qu'y a t-il alors comme alternative aux librairies dynamiques (à part les librairies statiques) ?

Comme indiqué, l'interface des DLL est de type C (pas des objets).
Celà n'empêche pas d'utiliser la POO à l'intérieur de la DLL.

Pour travailler avec une bibli externe objet dans Windows, La technologie COM+ (et DCOM) permet de définir un objet dans un process et de l'utiliser dans un autre qui n'en connait que l'interface.

C'est cette méthode qui permet de gérer des documents Word ou Excel via un applicatif. La mise en oeuvre est relativement simple : compter moins de 2 jours pour créer une première appli de test qui tourne, comprenant un programme "serveur" définissant l'objet COM et un programme "client" qui l'utilise.

[Luc Hermitte]

Les interfaces des DLLs peuvent parfaitement être en C++ -- tant qu'elles seront liées avec l'éditeur de liens venant avec le compilateur avec lequel elles ont été compilées.
(Et il existe des petites passerelles avec d'autres compilos C++)

Un plugin peut très bien être un script qui sera interprété depuis l'application principale (qui pourra exposer une API dans ce but). Les bibliothèques dynamiques sont en effet un autre moyen de s'y prendre.

[Jean-Marc.Bourguet]

Déjà pour alléger l'application (pour pas me retrouver avec un .exe énorme).

Je ne vois pas la différence entre un gros .EXE et un petit .EXE et deux cents cinquante .DLL.

Ensuite je trouve que c'est mieux de dispatcher le code dans différentes dll, ça donne une vision plus globale de l'ensemble

Je ne vois pas ce que la .DLL apporte par rappor à une lib statique de ce point de vue.

et ça permet de corriger/modifier plus facilement le code (on recompile juste la dll).

Vrai pour le développement. Mais pour le déploiement, un .EXE tout seul est beaucoup plus facile (le support n'a pas d'appel parce que quelqu'un a effacé ou écrasé une .DLL ou qu'une .DLL a été trouvée au mauvais endroit pour une raison ou une autre -- je ne connais pas assez Windows, mais réussir à faire une installation binaire robuste de programmes utilisant des .so sous Unix, c'est pas facile: je n'ai jamais vu le faire).

[Jean-Marc.Bourguet]

Il y a un cas qui n'a pas été cité mais qui me semble nécessiter l'utilisation de dll : les plugins d'une application.

C'est le seul ca où c'est réellement nécessaire. Mais combien d'applications ont réellement besoin de plugin et non simplement d'un langage de script?