OVH Cloud OVH Cloud

template et dll 2

55 réponses
Avatar
Boris Sargos
Salut à tous,

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.

10 réponses

2 3 4 5 6
Avatar
kanze
"Arnaud Debaene" wrote in message
news:<41a62036$0$289$...
wrote:
(Arnaud Debaene) wrote in message
news:...
Arnaud Meurgues wrote in message
news:<41a30ccb$0$6702$...

C'est fort possible. Je ne me suis jamais vraiment penché dessus,
j'avoue. Mais du coup, je me demande à quoi sert le .lib...


Essentiellement à résoudre les offsets des symboles de la DLL au
moment de l'édition de liens, et donc de diminuer le temps de
démarrage du programme (à l'execution, il n'y a plus qu'un offset à
appliquer pour tenir compte de l'addresse de chargement de la DLL).


Je n'ai rien compris de ton explication. Pour moi, un .lib, c'est
une bibliothèque non linkée, qu'on linke statiquement. Pour faire
soit un exécutable, soit un objet dynamique (.dll ou .so).


Oui, mais sous Windows il y a un autre type de fichiers : les
"librairies d'import" qui sont (à tort AMHA) nommées en ".lib" comme
les "vraies" librairies statiques. Une librairie d'import est générée
en même temps qu'une DLL et permet au linker de résoudre au link-time
les symboles de la DLL, mais elle ne contient pas de code en elle
même.


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?

--
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




Avatar
Matthieu Moy
writes:

Matthieu Moy wrote in message
news:...

Est-ce que tu considères le fichier /lib/libc.so.6 que j'ai sur mon
disque dur comme un plugin ou un executable ?


C'est un plugin, non ? C'est un plugin un peu spécial, dans le sens
qu'il y a beaucoup d'applications qui l'utilisent. Mais il fonctionne
comme un plugin, et existe pour à peu près la même raison : de
customiser ton application. Ici, le customiser en fonction de la version
de l'OS, etc. (et dans la pratique, il change assez peu pour que je ne
suis pas sûr qu'une édition de liens dynamiques se justifie).


Pour moi, un plugin, c'est un truc que je peux rajouter à une
application, pas un prérequis pour que mon applie puisse fonctionner.

Sinon, la raison principale pour laquelle /lib/libc.so.6 est
dynamique, c'est d'éviter d'avoir une copie de « printf » par
executable qui l'utilise par exemple. Dans mon vocabulaire, ça
s'appelle une « bibliothèque partagée » et non un « plugin ». Je ne
crois pas être le seul à utiliser cette terminologie, non ?

--
Matthieu


Avatar
tib.motuelle
Matthieu Moy wrote in message news:...
writes:

Matthieu Moy wrote in message
news:...

Est-ce que tu considères le fichier /lib/libc.so.6 que j'ai sur mon
disque dur comme un plugin ou un executable ?


C'est un plugin, non ? C'est un plugin un peu spécial, dans le sens
qu'il y a beaucoup d'applications qui l'utilisent. Mais il fonctionne
comme un plugin, et existe pour à peu près la même raison : de
customiser ton application. Ici, le customiser en fonction de la version
de l'OS, etc. (et dans la pratique, il change assez peu pour que je ne
suis pas sûr qu'une édition de liens dynamiques se justifie).



C'est à prendre à quel degré?

Pour moi, un plugin, c'est un truc que je peux rajouter à une
application, pas un prérequis pour que mon applie puisse fonctionner.


Je suis d'accord. Ton prog à toi est un plug-in de l'appli "OS" ;-)

Sinon, la raison principale pour laquelle /lib/libc.so.6 est
dynamique, c'est d'éviter d'avoir une copie de « printf » par
executable qui l'utilise par exemple. Dans mon vocabulaire, ça
s'appelle une « bibliothèque partagée » et non un « plugin ». Je ne
crois pas être le seul à utiliser cette terminologie, non ?


Non. Je partage ton avis.

Bertrand.



Avatar
Fabien LE LEZ
On 26 Nov 2004 02:05:40 -0800, :

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++.


--
;-)

Avatar
kanze
Matthieu Moy wrote in message
news:...
writes:

Matthieu Moy wrote in message
news:...

Est-ce que tu considères le fichier /lib/libc.so.6 que j'ai sur mon
disque dur comme un plugin ou un executable ?


C'est un plugin, non ? C'est un plugin un peu spécial, dans le sens
qu'il y a beaucoup d'applications qui l'utilisent. Mais il
fonctionne comme un plugin, et existe pour à peu près la même raison
: de customiser ton application. Ici, le customiser en fonction de
la version de l'OS, etc. (et dans la pratique, il change assez peu
pour que je ne suis pas sûr qu'une édition de liens dynamiques se
justifie).


Pour moi, un plugin, c'est un truc que je peux rajouter à une
application, pas un prérequis pour que mon applie puisse fonctionner.


Alors, c'est quoi ? C'est bien quelque chose qu'on ajoute à
l'application lors de l'execution, en fonction de l'environement.

Sinon, la raison principale pour laquelle /lib/libc.so.6 est
dynamique, c'est d'éviter d'avoir une copie de « printf » par
executable qui l'utilise par exemple.


C'était la motivation initiale, et ce qui a bien donné le nom. Mais ça
fait longtemps que ce n'est pas une motivation importante. (D'ailleurs,
quand l'espace disque était la motivation, on ne mettait pas libc dans
un objet partagé. Il n'était pas assez grand pourque ça vaut la peine.)

En revanche, au moins chez Sun, tu n'es pas garanti que ton application
fonctionne sur la prochaine version de Solaris si tu fais une édition de
liens statique de libc. Tandis qu'avec l'édition de liens dynamique,
même les applications de Sun OS 4 tourne sous Solaris 2.8.

Dans mon vocabulaire, ça s'appelle une « bibliothèque partagée » et
non un « plugin ». Je ne crois pas être le seul à utiliser cette
terminologie, non ?


À vrai dire, je ne l'ai jamais entendu. Le vocabulaire Unix dit souvent
« objet partagé » (« shared object », d'où .so), même pour les plugins
qu'on ne partage pas, et le vocabulaire Windows dit souvent DLL, même si
ce n'est pas une bibliothèque. Mais dans la mésure que c'est du tout ou
rien -- qu'on n'extrait pas des éléments de façon séparée, je ne crois
pas que le mot « bibliothèque » convient.

--
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



Avatar
Matthieu Moy
writes:

Matthieu Moy wrote in message
news:...

Pour moi, un plugin, c'est un truc que je peux rajouter à une
application, pas un prérequis pour que mon applie puisse fonctionner.


Alors, c'est quoi ? C'est bien quelque chose qu'on ajoute à
l'application lors de l'execution, en fonction de l'environement.


Par « quelque chose qu'on ajoute à l'application », j'entends « mon
application fonctionne, et je peux lui rajouter des choses », ce qui
était d'ailleurs clair en lisant la fin de ma phrase. Par exemple, mon
Mozilla fonctionne, mais je peux lui rajouter le /plugin/ java si je
veux.

(granddictionnaire.com est d'accord avec moi sur cette définition, et
donne comme traduction française de plugin un « plugiciel » comme
« PLUs » et « loGICIEL »)

Je me suis déjà « amusé » à désinstaller ma libc, je t'assure qu'il
n'y a plus grand chose qui marche après ;-)

Dans mon vocabulaire, ça s'appelle une « bibliothèque partagée » et
non un « plugin ». Je ne crois pas être le seul à utiliser cette
terminologie, non ?


À vrai dire, je ne l'ai jamais entendu.


« shared library » donne 1 000 000 résultats dans google (3 000
résultats pour « bibliothèque partagée »). Je t'assure, je suis pas le
seul à utiliser cette expression !! (même si j'utilise souvent aussi
« bibliothèque dynamique »)

--
Matthieu


Avatar
Gabriel Dos Reis
Fabien LE LEZ writes:

| On 26 Nov 2004 02:05:40 -0800, :
|
| >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++.

Oh.

-- Gaby
Avatar
Arnaud Debaene
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.

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...)

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?
- comment est-ce que le "name-mangling" des symboles C++ est géré? Le
run-time est capable de comprendre le mangling des différents compilateurs?
- 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?

Arnaud

Avatar
Loïc Joly
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),
Gain de disque dur,
C'est l'utiliseteur que décide comment il se lie, pas le fournisseur,
sans pour autant être obligé de livrer 2 versions,
Autre ?

--
Loïc

Avatar
James Kanze
Matthieu Moy writes:

|> writes:

|> > Matthieu Moy wrote in message
|> > news:...

|> >> Pour moi, un plugin, c'est un truc que je peux rajouter à une
|> >> application, pas un prérequis pour que mon applie puisse
|> >> fonctionner.
|
|> > Alors, c'est quoi ? C'est bien quelque chose qu'on ajoute à
|> > l'application lors de l'execution, en fonction de l'environement.

|> Par « quelque chose qu'on ajoute à l'application », j'entends « mon
|> application fonctionne, et je peux lui rajouter des choses », ce qui
|> était d'ailleurs clair en lisant la fin de ma phrase. Par exemple,
|> mon Mozilla fonctionne, mais je peux lui rajouter le /plugin/ java
|> si je veux.

|> (granddictionnaire.com est d'accord avec moi sur cette définition,
|> et donne comme traduction française de plugin un « plugiciel » comme
|> « PLUs » et « loGICIEL »)

|> Je me suis déjà « amusé » à désinstaller ma libc, je t'assure qu'il
|> n'y a plus grand chose qui marche après ;-)

Ne l'essaie pas -- je te crois sur parole:-).

Mais si on ne l'appelle pas un « plug-in », c'est quoi, alors ? C'est
bien quelque chose qui se comporte en tout égard comme un plug-in, sauf
que ton application ne fonctionne pas s'il n'est pas là.

Il y a aussi l'argument : qu'est-ce que tu entends par « fonctionner » ?
Sans le plug-in flash, Mozilla ne me permet pas de régarder un bon
nombre de sites. Maintenant, je dirais que Flash est un plug-in, même
selon ta définition, parce que j'arrive aussi à visiter pas mal de sites
sans flash. Mais il faut avouer que la définition est flou -- supposons
que Mozilla utilisait un plug-in pour la HTML ? Pour le JPEG et les
GIF ? Pour le Javascript ? À quel moment cessera-t-il d'être un
plug-in ?

|> >> Dans mon vocabulaire, ça s'appelle une « bibliothèque partagée »
|> >> et non un « plugin ». Je ne crois pas être le seul à utiliser
|> >> cette terminologie, non ?

|> > À vrai dire, je ne l'ai jamais entendu.

|> « shared library » donne 1 000 000 résultats dans google (3 000
|> résultats pour « bibliothèque partagée »). Je t'assure, je suis pas
|> le seul à utiliser cette expression !! (même si j'utilise souvent
|> aussi « bibliothèque dynamique »)

Apparamment. Mais j'avoue que j'ai bien plus souvent entendu « shared
object » (sous Unix) ou DLL (sous Windows).

--
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
2 3 4 5 6