A partir de quand estimez vous que faire une DLL plutot qu'un LIB soit
int=E9ressant. En effet, utiliser des DLL fait des programmes plus
petits (entre autres) mais induit d'enormes contraintes au niveau de la
programmation. Donc d'apres moi, faire une DLL pour une bibliotheque de
petite taille n'est pas forcement une bonne idee...
A partir de quand estimez vous que faire une DLL plutot qu'un LIB soit intéressant. En effet, utiliser des DLL fait des programmes plus petits (entre autres) mais induit d'enormes contraintes au niveau de la programmation. Donc d'apres moi, faire une DLL pour une bibliotheque de petite taille n'est pas forcement une bonne idee... Donc pour resumer les reponses, il apparait qu'il faut utiliser le
moins possible les DLL. Uniquement lorsque c'est obligatoire... Merci a tous pour vos reponses, pas toujours intelligibles mais merci quand meme...;)
K.
Korchkidu wrote:
Bonjour,
A partir de quand estimez vous que faire une DLL plutot qu'un LIB soit
intéressant. En effet, utiliser des DLL fait des programmes plus
petits (entre autres) mais induit d'enormes contraintes au niveau de la
programmation. Donc d'apres moi, faire une DLL pour une bibliotheque de
petite taille n'est pas forcement une bonne idee...
Donc pour resumer les reponses, il apparait qu'il faut utiliser le
moins possible les DLL. Uniquement lorsque c'est obligatoire... Merci a
tous pour vos reponses, pas toujours intelligibles mais merci quand
meme...;)
A partir de quand estimez vous que faire une DLL plutot qu'un LIB soit intéressant. En effet, utiliser des DLL fait des programmes plus petits (entre autres) mais induit d'enormes contraintes au niveau de la programmation. Donc d'apres moi, faire une DLL pour une bibliotheque de petite taille n'est pas forcement une bonne idee... Donc pour resumer les reponses, il apparait qu'il faut utiliser le
moins possible les DLL. Uniquement lorsque c'est obligatoire... Merci a tous pour vos reponses, pas toujours intelligibles mais merci quand meme...;)
K.
Bertrand Lenoir-Welter
:
Donc pour resumer les reponses, il apparait qu'il faut utiliser le moins possible les DLL. Uniquement lorsque c'est obligatoire...
C'est peut-être un peu raccourci, comme conclusion. A mon sens, il faut utiliser les DLL principalement - je dis bien *PRINCIPALEMENT* - lorsque 1- du code est partagé entre plusieurs programmes pour éviter d'encombrer la mémoire, ou 2- quand on veut faire des mises à jour partielles, avec quelques précautions de compatibilité dans ce cas, ou encore 3- quand un programme a besoin d'un module parmi plusieurs existants qui font la même chose vu du programme mais la font de façon différente pour chaque DLL ou dans des environnements différents.
Ma conclusion personnelle, c'est que 1- les mémoires actuelles sont vastes et qu'en dehors de quelques mammouths, les redondances de code en mémoire et sur disque ne sont pas un drame sauf pour quelques fondamentalistes monomaniaques de l'optimisation, et que 2- les supports de stockage et les vitesses de téléchargement actuelles font que, toujours en dehors des mammouths, les utilisateurs ne voient pas tous la différence entre la mise à jour d'une partie du code DLL ou du programme complet.
Le point 3 me semble a contrario le plus intéressant. Je prends mon cas personnel : je pilote avec différents modules d'un logiciel unique des machines-outils qui ont des protocoles de communication et des langages de commande complètement différents. Pour autant les fonctions vues des composants du logiciel sont toutes identiques. Dans ce cas, une DLL spécifique pour chaque type de machine devient intéressant, d'abord parce que ça évite de charger en mémoire le code pour toutes les machines alors qu'une seule est pilotée, ensuite parce que ça évite qu'une modif du code dans la DLL associée à la machine X ne vienne perturber le pilotage de celle de la machine Y, enfin parce que le code est plus standard et donc plus lisible et facile à maintenir. Dans ce dernier cas, donc, la différence entre une DLL et un driver de périphérique (par exemple d'imprimante) est qu'on fournit plusieurs DLL's dont une seule sera finalement utilisée, et ne sera utilisée que par l'application qu'on fournit. Donc pas besoin de descendre d'un niveau dans le système.
En post-scriptum, j'ajouterai que si tu ne vois pas un avantage immédiat à organiser ton programme avec des DLL, alors ne te complique pas l'existence en les utilisant. Ce qui rejoint ta propre conclusion. T'avais donc raccourci mais quand même bon.
benoit.lecallennec@gmail.com :
Donc pour resumer les reponses, il apparait qu'il faut utiliser le
moins possible les DLL. Uniquement lorsque c'est obligatoire...
C'est peut-être un peu raccourci, comme conclusion. A mon sens, il faut
utiliser les DLL principalement - je dis bien *PRINCIPALEMENT* - lorsque
1- du code est partagé entre plusieurs programmes pour éviter
d'encombrer la mémoire, ou 2- quand on veut faire des mises à jour
partielles, avec quelques précautions de compatibilité dans ce cas, ou
encore 3- quand un programme a besoin d'un module parmi plusieurs
existants qui font la même chose vu du programme mais la font de façon
différente pour chaque DLL ou dans des environnements différents.
Ma conclusion personnelle, c'est que 1- les mémoires actuelles sont
vastes et qu'en dehors de quelques mammouths, les redondances de code en
mémoire et sur disque ne sont pas un drame sauf pour quelques
fondamentalistes monomaniaques de l'optimisation, et que 2- les supports
de stockage et les vitesses de téléchargement actuelles font que,
toujours en dehors des mammouths, les utilisateurs ne voient pas tous la
différence entre la mise à jour d'une partie du code DLL ou du programme
complet.
Le point 3 me semble a contrario le plus intéressant. Je prends mon cas
personnel : je pilote avec différents modules d'un logiciel unique des
machines-outils qui ont des protocoles de communication et des langages
de commande complètement différents. Pour autant les fonctions vues des
composants du logiciel sont toutes identiques. Dans ce cas, une DLL
spécifique pour chaque type de machine devient intéressant, d'abord
parce que ça évite de charger en mémoire le code pour toutes les
machines alors qu'une seule est pilotée, ensuite parce que ça évite
qu'une modif du code dans la DLL associée à la machine X ne vienne
perturber le pilotage de celle de la machine Y, enfin parce que le code
est plus standard et donc plus lisible et facile à maintenir. Dans ce
dernier cas, donc, la différence entre une DLL et un driver de
périphérique (par exemple d'imprimante) est qu'on fournit plusieurs
DLL's dont une seule sera finalement utilisée, et ne sera utilisée que
par l'application qu'on fournit. Donc pas besoin de descendre d'un
niveau dans le système.
En post-scriptum, j'ajouterai que si tu ne vois pas un avantage immédiat
à organiser ton programme avec des DLL, alors ne te complique pas
l'existence en les utilisant. Ce qui rejoint ta propre conclusion.
T'avais donc raccourci mais quand même bon.
Donc pour resumer les reponses, il apparait qu'il faut utiliser le moins possible les DLL. Uniquement lorsque c'est obligatoire...
C'est peut-être un peu raccourci, comme conclusion. A mon sens, il faut utiliser les DLL principalement - je dis bien *PRINCIPALEMENT* - lorsque 1- du code est partagé entre plusieurs programmes pour éviter d'encombrer la mémoire, ou 2- quand on veut faire des mises à jour partielles, avec quelques précautions de compatibilité dans ce cas, ou encore 3- quand un programme a besoin d'un module parmi plusieurs existants qui font la même chose vu du programme mais la font de façon différente pour chaque DLL ou dans des environnements différents.
Ma conclusion personnelle, c'est que 1- les mémoires actuelles sont vastes et qu'en dehors de quelques mammouths, les redondances de code en mémoire et sur disque ne sont pas un drame sauf pour quelques fondamentalistes monomaniaques de l'optimisation, et que 2- les supports de stockage et les vitesses de téléchargement actuelles font que, toujours en dehors des mammouths, les utilisateurs ne voient pas tous la différence entre la mise à jour d'une partie du code DLL ou du programme complet.
Le point 3 me semble a contrario le plus intéressant. Je prends mon cas personnel : je pilote avec différents modules d'un logiciel unique des machines-outils qui ont des protocoles de communication et des langages de commande complètement différents. Pour autant les fonctions vues des composants du logiciel sont toutes identiques. Dans ce cas, une DLL spécifique pour chaque type de machine devient intéressant, d'abord parce que ça évite de charger en mémoire le code pour toutes les machines alors qu'une seule est pilotée, ensuite parce que ça évite qu'une modif du code dans la DLL associée à la machine X ne vienne perturber le pilotage de celle de la machine Y, enfin parce que le code est plus standard et donc plus lisible et facile à maintenir. Dans ce dernier cas, donc, la différence entre une DLL et un driver de périphérique (par exemple d'imprimante) est qu'on fournit plusieurs DLL's dont une seule sera finalement utilisée, et ne sera utilisée que par l'application qu'on fournit. Donc pas besoin de descendre d'un niveau dans le système.
En post-scriptum, j'ajouterai que si tu ne vois pas un avantage immédiat à organiser ton programme avec des DLL, alors ne te complique pas l'existence en les utilisant. Ce qui rejoint ta propre conclusion. T'avais donc raccourci mais quand même bon.
