n'ayant pas eu de réponse à mon post précédent, je suppose qu'il n'était pas
très clair. Je m'en excuse, et je reformule autrement ma question. Donc, à
quoi cela sert-il d'écrire des classes templates dans une DLL si elles ne
peuvent être exportées ?
Pour aller plus loin, comme de nombreuses applications sont décomposées en
DLLs, le template est-il utilisé ?
Dans mon cas, j'ai écrit une DLL de fonctions mathématiques à base de
templates, mais je me retrouve coincé, car je ne peux l'utiliser dans mes
applications. Faut donc t-il tout écrire sans dll, dans un seul bloc de
programme ?
J'aimerais avoir votre point de vue sur ce point.
Merci à tous.
|> >Alors, où est l'intérêt de l'édition de liens dynamque?
|> Il arrive que l'édition de liens statiques ne fonctionne pas. |> Notamment quand on doit linker une bibliothèque prévue pour gcc avec |> un programme écrit en Borland C++.
Et la même interface marche en édition de liens dynamiques ?
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Fabien LE LEZ <gramster@gramster.com> writes:
|> On 26 Nov 2004 02:05:40 -0800, kanze@gabi-soft.fr:
|> >Alors, où est l'intérêt de l'édition de liens dynamque?
|> Il arrive que l'édition de liens statiques ne fonctionne pas.
|> Notamment quand on doit linker une bibliothèque prévue pour gcc avec
|> un programme écrit en Borland C++.
Et la même interface marche en édition de liens dynamiques ?
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> >Alors, où est l'intérêt de l'édition de liens dynamque?
|> Il arrive que l'édition de liens statiques ne fonctionne pas. |> Notamment quand on doit linker une bibliothèque prévue pour gcc avec |> un programme écrit en Borland C++.
Et la même interface marche en édition de liens dynamiques ?
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
James Kanze
"Arnaud Debaene" writes:
|> wrote: |> > Et comment ça peut-il marcher ? Si j'ai des offsets en dur dans |> > mon executable, je suis obligé à ne charger que la DLL avec |> > laquelle j'ai linké.
|> Pas tout à fait. J'ai vérifié et ma description était un peu |> imprécise : En fait la librairie d'import ne fournit pas au linker |> les offsets des symboles dans la DLL, mais plutôt l'index de chaque |> symbole dans la table d'export de la DLL. Cette table d'adresses est |> placée dans l'en-tête de la DLL. Lorsque la DLL est chargée, une |> copie de cette table est faite en mémoire et chaque entrée est |> modifiée par l'offset de chargement de la DLL. De cette manière, à |> l'exécution, il suffit de lire l'entrée dans cette table |> correspondant à l'index qui était référencé dans la librairie |> d'import, et on a directement l'adresse du symbole correspondant, ce |> qui limite le coût d'appel au maximum (juste un indirection).
|> L'intérêt est donc : |> - D'éviter de devoir faire la moindre recherche/résolution de |> symbole à l'execution. |> - De permettre de changer la DLL après l'édition de liens tant que |> la table de symboles exportés reste identique (même index pour |> chaque symbole). C'est la remarque de Fabien qui m'a mis la puce à |> l'oreille et m'a poussé à vérifier.
OK. En fait, il s'agit bien d'une édition de liens dynamiques, avec une optimisation du chargement, qu'on paie par une pessimisation (un niveau d'indirection de plus) à l'exécution. Selon le cas, ça peut être intéressant.
|> > Alors, où est l'intérêt de l'édition de liens dynamque?
|> Mais il est parfaitement possible de faire de l'édition de lien |> vraiement dynamique, il suffit de ne pas se lier à la librairie |> d'import et de charger explicitement la DLL! Dans ce cas, on utilise |> LoadLibrary et GetProcAddress, mais la syntaxe est beaucoup plus |> lourde (au point d'être quasi-inutilisable avec des symboles C++ |> manglés...)
Mais même ce que tu décris ci-dessus, c'est une édition de liens dynamique. Avec d'autres trade-offs.
|> Au fait, comment est-ce que cette édition de liens dynamique est |> faite sous Linux? Comme il n'y a pas de librairie d'import, je |> suppose que ca veut dire que la résolution de symbole est faite au |> run-time mais ca me pose plusieurs questions :
|> - le .so embarque obligatoirement des "informations de debogage", en |> tout cas suffisamment pour pouvoir résoudre les noms des symboles |> exportés. Exact?
Il contient bien les symboles « exportés ». Par défaut, tout symbole extern. (Je crois qu'on peut dédéfinir des symboles par la suite, pour qu'ils ne soient plus visible, mais je ne m'y suis jamais reseigné. En fait, la solution Unix pour ne pas avoir des symboles non voulus visible, c'est de passer un paramètre spécial au dlopen.) Au moins qu'on ne le démande, il ne contient pas les numéros de lignes, les variables et les fonctions statiques, ni les variables locales.
|> - comment est-ce que le "name-mangling" des symboles C++ est géré?
À la main:-).
En général, il y a deux cas distincts :
- L'objet est chargée implicitement lors du démarrage. Il y a une fonction système qui s'occupe de tout ; je ne sais donc pas exactement comment ça se fait. Mais tu dois bien précisé la bibliothèque partagée lors de l'édition de liens statiques -- je suppose que l'éditeur de liens se contente de laisser les externes non-résolus s'ils sont définis dans un des .so. (Souvent, et selon les options, l'éditeur de liens met aussi quelques informations en ce qui concerne la version de la bibliothèque, et éventuellement où il faut la chercher.)
- Tu charge l'object explicitement, au moyen de dlopen. Alors, c'est à toi de jouer ; tu as pas mal de liberté avec les options de dlopen, en ce qui concerne ce que voit les autres objets dynamiques. Mais quand tu passes un nom d'une fonction à dlsym, il faut bien le nom décoré, tel qu'il apparaît dans le .o et le .so qui en dérive.
|> Le run-time est capable de comprendre le mangling des différents |> compilateurs?
À vrai dire, je ne l'ai jamais essayé (sauf avec les modules C), mais je le doute. Tu ne peux pas le faire avec une édition de liens statiques, alors...
À une exception près : si tu charges l'objet avec dlopen, en lui donnant l'option pour que les symboles ne soient pas implicitement visible partout, il ne doit pas y avoir de problème, dans la mésure que l'objet n'appelle pas des fonctions C++ dans d'autres objets, et que tu donnes le nom « bien » à l'appel de dlsym.
|> - de manière plus générale, est-ce qu'un .so créé avec un outil de |> développement donné peut facilement être utilisé par un programme |> écrit avec un autre outil?
En général, non. Mais ça dépend des outils. Dans le cas de C++, par exemple, les differences dans la décoration des noms est là pour une raison. Si l'organisation en mémoire d'une classe diffère d'un compilateur à l'autre, ce n'est pas parce que tu réussis à trouver le nom que le code va marcher. Au contraire.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> kanze@gabi-soft.fr wrote:
|> > Et comment ça peut-il marcher ? Si j'ai des offsets en dur dans
|> > mon executable, je suis obligé à ne charger que la DLL avec
|> > laquelle j'ai linké.
|> Pas tout à fait. J'ai vérifié et ma description était un peu
|> imprécise : En fait la librairie d'import ne fournit pas au linker
|> les offsets des symboles dans la DLL, mais plutôt l'index de chaque
|> symbole dans la table d'export de la DLL. Cette table d'adresses est
|> placée dans l'en-tête de la DLL. Lorsque la DLL est chargée, une
|> copie de cette table est faite en mémoire et chaque entrée est
|> modifiée par l'offset de chargement de la DLL. De cette manière, à
|> l'exécution, il suffit de lire l'entrée dans cette table
|> correspondant à l'index qui était référencé dans la librairie
|> d'import, et on a directement l'adresse du symbole correspondant, ce
|> qui limite le coût d'appel au maximum (juste un indirection).
|> L'intérêt est donc :
|> - D'éviter de devoir faire la moindre recherche/résolution de
|> symbole à l'execution.
|> - De permettre de changer la DLL après l'édition de liens tant que
|> la table de symboles exportés reste identique (même index pour
|> chaque symbole). C'est la remarque de Fabien qui m'a mis la puce à
|> l'oreille et m'a poussé à vérifier.
OK. En fait, il s'agit bien d'une édition de liens dynamiques, avec une
optimisation du chargement, qu'on paie par une pessimisation (un niveau
d'indirection de plus) à l'exécution. Selon le cas, ça peut être
intéressant.
|> > Alors, où est l'intérêt de l'édition de liens dynamque?
|> Mais il est parfaitement possible de faire de l'édition de lien
|> vraiement dynamique, il suffit de ne pas se lier à la librairie
|> d'import et de charger explicitement la DLL! Dans ce cas, on utilise
|> LoadLibrary et GetProcAddress, mais la syntaxe est beaucoup plus
|> lourde (au point d'être quasi-inutilisable avec des symboles C++
|> manglés...)
Mais même ce que tu décris ci-dessus, c'est une édition de liens
dynamique. Avec d'autres trade-offs.
|> Au fait, comment est-ce que cette édition de liens dynamique est
|> faite sous Linux? Comme il n'y a pas de librairie d'import, je
|> suppose que ca veut dire que la résolution de symbole est faite au
|> run-time mais ca me pose plusieurs questions :
|> - le .so embarque obligatoirement des "informations de debogage", en
|> tout cas suffisamment pour pouvoir résoudre les noms des symboles
|> exportés. Exact?
Il contient bien les symboles « exportés ». Par défaut, tout symbole
extern. (Je crois qu'on peut dédéfinir des symboles par la suite, pour
qu'ils ne soient plus visible, mais je ne m'y suis jamais reseigné. En
fait, la solution Unix pour ne pas avoir des symboles non voulus
visible, c'est de passer un paramètre spécial au dlopen.) Au moins qu'on
ne le démande, il ne contient pas les numéros de lignes, les variables
et les fonctions statiques, ni les variables locales.
|> - comment est-ce que le "name-mangling" des symboles C++ est géré?
À la main:-).
En général, il y a deux cas distincts :
- L'objet est chargée implicitement lors du démarrage. Il y a une
fonction système qui s'occupe de tout ; je ne sais donc pas
exactement comment ça se fait. Mais tu dois bien précisé la
bibliothèque partagée lors de l'édition de liens statiques -- je
suppose que l'éditeur de liens se contente de laisser les externes
non-résolus s'ils sont définis dans un des .so. (Souvent, et selon
les options, l'éditeur de liens met aussi quelques informations en
ce qui concerne la version de la bibliothèque, et éventuellement où
il faut la chercher.)
- Tu charge l'object explicitement, au moyen de dlopen. Alors, c'est à
toi de jouer ; tu as pas mal de liberté avec les options de dlopen,
en ce qui concerne ce que voit les autres objets dynamiques. Mais
quand tu passes un nom d'une fonction à dlsym, il faut bien le nom
décoré, tel qu'il apparaît dans le .o et le .so qui en dérive.
|> Le run-time est capable de comprendre le mangling des différents
|> compilateurs?
À vrai dire, je ne l'ai jamais essayé (sauf avec les modules C), mais je
le doute. Tu ne peux pas le faire avec une édition de liens statiques,
alors...
À une exception près : si tu charges l'objet avec dlopen, en lui donnant
l'option pour que les symboles ne soient pas implicitement visible
partout, il ne doit pas y avoir de problème, dans la mésure que l'objet
n'appelle pas des fonctions C++ dans d'autres objets, et que tu donnes
le nom « bien » à l'appel de dlsym.
|> - de manière plus générale, est-ce qu'un .so créé avec un outil de
|> développement donné peut facilement être utilisé par un programme
|> écrit avec un autre outil?
En général, non. Mais ça dépend des outils. Dans le cas de C++, par
exemple, les differences dans la décoration des noms est là pour une
raison. Si l'organisation en mémoire d'une classe diffère d'un
compilateur à l'autre, ce n'est pas parce que tu réussis à trouver le
nom que le code va marcher. Au contraire.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> wrote: |> > Et comment ça peut-il marcher ? Si j'ai des offsets en dur dans |> > mon executable, je suis obligé à ne charger que la DLL avec |> > laquelle j'ai linké.
|> Pas tout à fait. J'ai vérifié et ma description était un peu |> imprécise : En fait la librairie d'import ne fournit pas au linker |> les offsets des symboles dans la DLL, mais plutôt l'index de chaque |> symbole dans la table d'export de la DLL. Cette table d'adresses est |> placée dans l'en-tête de la DLL. Lorsque la DLL est chargée, une |> copie de cette table est faite en mémoire et chaque entrée est |> modifiée par l'offset de chargement de la DLL. De cette manière, à |> l'exécution, il suffit de lire l'entrée dans cette table |> correspondant à l'index qui était référencé dans la librairie |> d'import, et on a directement l'adresse du symbole correspondant, ce |> qui limite le coût d'appel au maximum (juste un indirection).
|> L'intérêt est donc : |> - D'éviter de devoir faire la moindre recherche/résolution de |> symbole à l'execution. |> - De permettre de changer la DLL après l'édition de liens tant que |> la table de symboles exportés reste identique (même index pour |> chaque symbole). C'est la remarque de Fabien qui m'a mis la puce à |> l'oreille et m'a poussé à vérifier.
OK. En fait, il s'agit bien d'une édition de liens dynamiques, avec une optimisation du chargement, qu'on paie par une pessimisation (un niveau d'indirection de plus) à l'exécution. Selon le cas, ça peut être intéressant.
|> > Alors, où est l'intérêt de l'édition de liens dynamque?
|> Mais il est parfaitement possible de faire de l'édition de lien |> vraiement dynamique, il suffit de ne pas se lier à la librairie |> d'import et de charger explicitement la DLL! Dans ce cas, on utilise |> LoadLibrary et GetProcAddress, mais la syntaxe est beaucoup plus |> lourde (au point d'être quasi-inutilisable avec des symboles C++ |> manglés...)
Mais même ce que tu décris ci-dessus, c'est une édition de liens dynamique. Avec d'autres trade-offs.
|> Au fait, comment est-ce que cette édition de liens dynamique est |> faite sous Linux? Comme il n'y a pas de librairie d'import, je |> suppose que ca veut dire que la résolution de symbole est faite au |> run-time mais ca me pose plusieurs questions :
|> - le .so embarque obligatoirement des "informations de debogage", en |> tout cas suffisamment pour pouvoir résoudre les noms des symboles |> exportés. Exact?
Il contient bien les symboles « exportés ». Par défaut, tout symbole extern. (Je crois qu'on peut dédéfinir des symboles par la suite, pour qu'ils ne soient plus visible, mais je ne m'y suis jamais reseigné. En fait, la solution Unix pour ne pas avoir des symboles non voulus visible, c'est de passer un paramètre spécial au dlopen.) Au moins qu'on ne le démande, il ne contient pas les numéros de lignes, les variables et les fonctions statiques, ni les variables locales.
|> - comment est-ce que le "name-mangling" des symboles C++ est géré?
À la main:-).
En général, il y a deux cas distincts :
- L'objet est chargée implicitement lors du démarrage. Il y a une fonction système qui s'occupe de tout ; je ne sais donc pas exactement comment ça se fait. Mais tu dois bien précisé la bibliothèque partagée lors de l'édition de liens statiques -- je suppose que l'éditeur de liens se contente de laisser les externes non-résolus s'ils sont définis dans un des .so. (Souvent, et selon les options, l'éditeur de liens met aussi quelques informations en ce qui concerne la version de la bibliothèque, et éventuellement où il faut la chercher.)
- Tu charge l'object explicitement, au moyen de dlopen. Alors, c'est à toi de jouer ; tu as pas mal de liberté avec les options de dlopen, en ce qui concerne ce que voit les autres objets dynamiques. Mais quand tu passes un nom d'une fonction à dlsym, il faut bien le nom décoré, tel qu'il apparaît dans le .o et le .so qui en dérive.
|> Le run-time est capable de comprendre le mangling des différents |> compilateurs?
À vrai dire, je ne l'ai jamais essayé (sauf avec les modules C), mais je le doute. Tu ne peux pas le faire avec une édition de liens statiques, alors...
À une exception près : si tu charges l'objet avec dlopen, en lui donnant l'option pour que les symboles ne soient pas implicitement visible partout, il ne doit pas y avoir de problème, dans la mésure que l'objet n'appelle pas des fonctions C++ dans d'autres objets, et que tu donnes le nom « bien » à l'appel de dlsym.
|> - de manière plus générale, est-ce qu'un .so créé avec un outil de |> développement donné peut facilement être utilisé par un programme |> écrit avec un autre outil?
En général, non. Mais ça dépend des outils. Dans le cas de C++, par exemple, les differences dans la décoration des noms est là pour une raison. Si l'organisation en mémoire d'une classe diffère d'un compilateur à l'autre, ce n'est pas parce que tu réussis à trouver le nom que le code va marcher. Au contraire.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
James Kanze
Loïc Joly writes:
|> wrote: |> [dll liée 'statiquement']
|> > Et comment ça peut-il marcher ? Si j'ai des offsets en dur dans |> > mon executable, je suis obligé à ne charger que la DLL avec |> > laquelle j'ai linké. Alors, où est l'intérêt de l'édition de liens |> > dynamque?
|> Interlangage (ceux qui causent C peuvent utiliser le .lib, les |> autres font le boulot à la main),
Ce qui est aussi vrai avec une édition de liens statique.
|> Gain de disque dur,
Est-ce un argument aujourd'hui ? (Et note bien que de toute façon, il ne vaut que si toutes les applications utilisent la même version. Donc, en pratique, que pour des bibliothèques système.)
|> C'est l'utiliseteur que décide comment il se lie, pas le |> fournisseur, sans pour autant être obligé de livrer 2 versions,
Je ne comprends pas. Tu veux dire que l'application pose des questions à l'utilisateur, pour décider s'il veut utiliser la version de la bibliothèque lié statiquement avec l'application, ou charger dynamiquement une version inconnue et non testée ? Si c'est ça, je ne vois pas d'avantage.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> > Et comment ça peut-il marcher ? Si j'ai des offsets en dur dans
|> > mon executable, je suis obligé à ne charger que la DLL avec
|> > laquelle j'ai linké. Alors, où est l'intérêt de l'édition de liens
|> > dynamque?
|> Interlangage (ceux qui causent C peuvent utiliser le .lib, les
|> autres font le boulot à la main),
Ce qui est aussi vrai avec une édition de liens statique.
|> Gain de disque dur,
Est-ce un argument aujourd'hui ? (Et note bien que de toute façon, il ne
vaut que si toutes les applications utilisent la même version. Donc, en
pratique, que pour des bibliothèques système.)
|> C'est l'utiliseteur que décide comment il se lie, pas le
|> fournisseur, sans pour autant être obligé de livrer 2 versions,
Je ne comprends pas. Tu veux dire que l'application pose des questions à
l'utilisateur, pour décider s'il veut utiliser la version de la
bibliothèque lié statiquement avec l'application, ou charger
dynamiquement une version inconnue et non testée ? Si c'est ça, je ne
vois pas d'avantage.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> > Et comment ça peut-il marcher ? Si j'ai des offsets en dur dans |> > mon executable, je suis obligé à ne charger que la DLL avec |> > laquelle j'ai linké. Alors, où est l'intérêt de l'édition de liens |> > dynamque?
|> Interlangage (ceux qui causent C peuvent utiliser le .lib, les |> autres font le boulot à la main),
Ce qui est aussi vrai avec une édition de liens statique.
|> Gain de disque dur,
Est-ce un argument aujourd'hui ? (Et note bien que de toute façon, il ne vaut que si toutes les applications utilisent la même version. Donc, en pratique, que pour des bibliothèques système.)
|> C'est l'utiliseteur que décide comment il se lie, pas le |> fournisseur, sans pour autant être obligé de livrer 2 versions,
Je ne comprends pas. Tu veux dire que l'application pose des questions à l'utilisateur, pour décider s'il veut utiliser la version de la bibliothèque lié statiquement avec l'application, ou charger dynamiquement une version inconnue et non testée ? Si c'est ça, je ne vois pas d'avantage.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Loïc Joly
James Kanze wrote:
|> C'est l'utiliseteur que décide comment il se lie, pas le |> fournisseur, sans pour autant être obligé de livrer 2 versions,
Je ne comprends pas. Tu veux dire que l'application pose des questions à l'utilisateur, pour décider s'il veut utiliser la version de la bibliothèque lié statiquement avec l'application, ou charger dynamiquement une version inconnue et non testée ? Si c'est ça, je ne vois pas d'avantage.
Par utilisateur, j'entendais développeur qui utilise la lib.
-- Loïc
James Kanze wrote:
|> C'est l'utiliseteur que décide comment il se lie, pas le
|> fournisseur, sans pour autant être obligé de livrer 2 versions,
Je ne comprends pas. Tu veux dire que l'application pose des questions à
l'utilisateur, pour décider s'il veut utiliser la version de la
bibliothèque lié statiquement avec l'application, ou charger
dynamiquement une version inconnue et non testée ? Si c'est ça, je ne
vois pas d'avantage.
Par utilisateur, j'entendais développeur qui utilise la lib.
|> C'est l'utiliseteur que décide comment il se lie, pas le |> fournisseur, sans pour autant être obligé de livrer 2 versions,
Je ne comprends pas. Tu veux dire que l'application pose des questions à l'utilisateur, pour décider s'il veut utiliser la version de la bibliothèque lié statiquement avec l'application, ou charger dynamiquement une version inconnue et non testée ? Si c'est ça, je ne vois pas d'avantage.
Par utilisateur, j'entendais développeur qui utilise la lib.
-- Loïc
kanze
Loïc Joly wrote in message news:<41ab9566$0$9021$...
James Kanze wrote:
|> C'est l'utiliseteur que décide comment il se lie, pas le |> fournisseur, sans pour autant être obligé de livrer 2 versions,
Je ne comprends pas. Tu veux dire que l'application pose des questions à l'utilisateur, pour décider s'il veut utiliser la version de la bibliothèque lié statiquement avec l'application, ou charger dynamiquement une version inconnue et non testée ? Si c'est ça, je ne vois pas d'avantage.
Par utilisateur, j'entendais développeur qui utilise la lib.
OK.
C'est sûr que le client est roi, et s'il veut une bibliothèque dynamique, même si ça n'a aucun sens technique, on va lui fournir une bibliothèque dynamique.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in message
news:<41ab9566$0$9021$8fcfb975@news.wanadoo.fr>...
James Kanze wrote:
|> C'est l'utiliseteur que décide comment il se lie, pas le
|> fournisseur, sans pour autant être obligé de livrer 2 versions,
Je ne comprends pas. Tu veux dire que l'application pose des
questions à l'utilisateur, pour décider s'il veut utiliser la
version de la bibliothèque lié statiquement avec l'application, ou
charger dynamiquement une version inconnue et non testée ? Si c'est
ça, je ne vois pas d'avantage.
Par utilisateur, j'entendais développeur qui utilise la lib.
OK.
C'est sûr que le client est roi, et s'il veut une bibliothèque
dynamique, même si ça n'a aucun sens technique, on va lui fournir une
bibliothèque dynamique.
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Loïc Joly wrote in message news:<41ab9566$0$9021$...
James Kanze wrote:
|> C'est l'utiliseteur que décide comment il se lie, pas le |> fournisseur, sans pour autant être obligé de livrer 2 versions,
Je ne comprends pas. Tu veux dire que l'application pose des questions à l'utilisateur, pour décider s'il veut utiliser la version de la bibliothèque lié statiquement avec l'application, ou charger dynamiquement une version inconnue et non testée ? Si c'est ça, je ne vois pas d'avantage.
Par utilisateur, j'entendais développeur qui utilise la lib.
OK.
C'est sûr que le client est roi, et s'il veut une bibliothèque dynamique, même si ça n'a aucun sens technique, on va lui fournir une bibliothèque dynamique.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
