template et dll 2

Jean-Marc Bourguet wrote:

Export fonctionne aussi avec des librairies partagées ?
Qu'entends-tu par "fonctionne"?

J'entends : Est-ce que les compilateurs qui implémentent export et qui
permettent de mettre des template dans des bibliothèque (.a) savent les
mettre dans des bibliothèques partagées (.so) ?

Les implémentations disponibles actuellement ont besoin de
la définition des templates même avec export.

Oui. C'est pourquoi j'étais un peu surpris de lire que "export" serait
la solution pour autoriser des templates dans des dll.

Même une implémentation qui mettrait cette définition sous
une forme précompilée dans un .o (ce qui avec un format
ayant la souplesse d'elf me semble possible) ne pourrait
vraissemblablement pas mettre cette version précompilée dans
un .so. Certainement pas un .so qui serait chargé
dynamiquement.

Voui. C'était bien le sens de ma question.
Encore que pour les dll, le problème puisse être un peu différent
puisqu'il semble qu'il y ait un .lib associer qui pourrait peut-être, du
coup, comporter les infos nécessaire pour le template sans être obligé
de faire de la liaison dynamique.

--
Arnaud
(Supprimez les geneurs pour me répondre)

Arnaud Meurgues <arnaud@meurgues.non.fr.invalid> writes:

Jean-Marc Bourguet wrote:

Export fonctionne aussi avec des librairies partagées ?
Qu'entends-tu par "fonctionne"?

J'entends : Est-ce que les compilateurs qui implémentent export et qui
permettent de mettre des template dans des bibliothèque (.a)

Il n'y en a pas a ma connaissance.

savent les mettre dans des bibliothèques partagées (.so) ?

Les implémentations disponibles actuellement ont besoin de la
définition des templates même avec export.

Oui. C'est pourquoi j'étais un peu surpris de lire que "export"
serait la solution pour autoriser des templates dans des dll.

Je crois qu'il faut se mefier de tout ce qui est dit sur export par
ceux qui ne l'utilisent pas.

Même une implémentation qui mettrait cette définition sous une
forme précompilée dans un .o (ce qui avec un format ayant la
souplesse d'elf me semble possible) ne pourrait vraissemblablement
pas mettre cette version précompilée dans un .so. Certainement
pas un .so qui serait chargé dynamiquement.

Voui. C'était bien le sens de ma question.
Encore que pour les dll, le problème puisse être un peu différent puisqu'il
semble qu'il y ait un .lib associer qui pourrait peut-être, du coup,
comporter les infos nécessaire pour le template sans être obligé de faire
de la liaison dynamique.

J'avais cru comprendre qu'il etait possible de recreer ce .lib a
partir de la dll. Mais je ne connais pas grand chose a Windows, de
meme que je ne sais pas si le format .lib est capable d'embarquer des
choses plus ou moins arbitraire.

En fait tout est possible si on embarque tout le compilateur C++ dans
le run-time (ce qui s'est fait pour des systemes lisp).

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Merci, ça semble assez clair.
Je te demanderais juste une petite précision. Dans le cas d'une librairie
mathématique d'assez bas niveau tu sembles préconiser les templates.
D'accord avec ça. Mais cette librairie sera utilisable dans plein d'autres
parties du programme, si ce n'est même plusieurs programmes. Or les
templates non spécialisés (et c'est ce qui m'intéresse) n'étant pas
exportables, il serait stupide d'écrire cette librairie sous forme de dll.
Je ne sais pas comment fonctionne la stl, mais la solution pour ma librairie
mathématique ne serait-elle pas de l'écrire sous forme de librairie statique
?

Encore merci.

Boris Sargos wrote:

Je te demanderais juste une petite précision. Dans le cas d'une librairie
mathématique d'assez bas niveau tu sembles préconiser les templates.
D'accord avec ça. Mais cette librairie sera utilisable dans plein d'autres
parties du programme, si ce n'est même plusieurs programmes. Or les
templates non spécialisés (et c'est ce qui m'intéresse) n'étant pas
exportables, il serait stupide d'écrire cette librairie sous forme de dll.
Je ne sais pas comment fonctionne la stl, mais la solution pour ma librairie
mathématique ne serait-elle pas de l'écrire sous forme de librairie statique
?

La solution, actuellement, c'est que la "librairie" n'est finalement
qu'un ensemble de .h contenant le code des templates, à part pour les
quelques compilateurs implémentant export.

--
Arnaud
(Supprimez les geneurs pour me répondre)

Jean-Marc Bourguet wrote:

J'entends : Est-ce que les compilateurs qui implémentent export et qui
permettent de mettre des template dans des bibliothèque (.a)
Il n'y en a pas a ma connaissance.

Ah ? Les compilos qui implémentent export ne permettent pas de faire des
libs ?

Que permettent-ils de faire, alors ? juste un .o ? Et quelle est la
différence entre une lib et un .o ?

J'avais cru comprendre qu'il etait possible de recreer ce .lib a
partir de la dll.

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

En fait tout est possible si on embarque tout le compilateur C++ dans
le run-time (ce qui s'est fait pour des systemes lisp).

Certes. Mais je soupçonne qu'un compilateur C++ est moins "embarquable"
qu'un compilo Lisp.

--
Arnaud
(Supprimez les geneurs pour me répondre)

Et oui, tout simplement ! Je ne comprenais pas pourquoi la stl n'employait
pas de .cpp ...
Là, j'ai tout pigé.
Merci à tous.

Arnaud Meurgues <arnaud@meurgues.non.fr.invalid> writes:

Jean-Marc Bourguet wrote:

J'entends : Est-ce que les compilateurs qui implémentent export et qui
permettent de mettre des template dans des bibliothèque (.a)
Il n'y en a pas a ma connaissance.

Ah ? Les compilos qui implémentent export ne permettent pas de faire
des libs ?

Si. Mais pas avec les definitions des templates. Celles-ci sont a
fournir de la meme maniere que tu fournis les declarations (les .h)
maintenant.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

"Boris Sargos" <bsargos@wanadoo.fr> wrote in message
news:<41a3060f$0$29143$8fcfb975@news.wanadoo.fr>...

Je te demanderais juste une petite précision. Dans le cas d'une
librairie mathématique d'assez bas niveau tu sembles préconiser les
templates.

Je ne préconcise rien. J'imagine seulement que c'est un domain où
l'utilisation des templates se justifient parfois.

D'accord avec ça. Mais cette librairie sera utilisable dans plein
d'autres parties du programme, si ce n'est même plusieurs programmes.
Or les templates non spécialisés (et c'est ce qui m'intéresse) n'étant
pas exportables, il serait stupide d'écrire cette librairie sous forme
de dll.

Tout à fait d'accord. D'ailleurs, je ne vois pas trop d'intérêt à
deployer une bibliothèque mathématique sous forme de DLL. Où en est
l'avantage ? (L'intérêt d'une DLL, c'est surtout quand ta bibliothèque
implémente une passerelle.)

Je ne sais pas comment fonctionne la stl, mais la solution pour ma
librairie mathématique ne serait-elle pas de l'écrire sous forme de
librairie statique ?

Avec les templates, actuellement, c'est plutôt une question de livrer
les sources, avec tous les desavantages que ça comporte en ce qui
concerne la fiabilité.

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

Arnaud Meurgues wrote:

Jean-Marc Bourguet wrote:

J'entends : Est-ce que les compilateurs qui implémentent export et qui
permettent de mettre des template dans des bibliothèque (.a)

Il n'y en a pas a ma connaissance.

Ah ? Les compilos qui implémentent export ne permettent pas de faire des
libs ?

Que permettent-ils de faire, alors ? juste un .o ? Et quelle est la
différence entre une lib et un .o ?

J'avais cru comprendre qu'il etait possible de recreer ce .lib a
partir de la dll.

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

Il y a deux types de .lib :

Les vrais, ceux qui ont du code dedans.
Les faux, qui ne servent que de ".h" à une DLL, dans le cas où l'on
souhaite se liér statiquement à elle. De mémoire il manque 2/3 chose à
une DLL pour qu'on puisse générer ce .lib à partir d'elle (les arguments
et types de retour des fonctons ?). Par contre, il me semble clair qu'à
parti de ces .lib, la génération d'un .h est possible.

Maintenant, il existe des DLL spéciales (les DLL com, les DLL.NET) qui
elles peuvent fournir plus d'info.

--
Loïc
(qui ne parle que de mémoire et sans certitude sur ce sujet)

Arnaud Meurgues <arnaud@meurgues.non.fr.invalid> wrote in message
news:<41a30ccb$0$6702$626a14ce@news.free.fr>...

Jean-Marc Bourguet wrote:

J'entends : Est-ce que les compilateurs qui implémentent export et
qui permettent de mettre des template dans des bibliothèque (.a)

Il n'y en a pas a ma connaissance.

Ah ? Les compilos qui implémentent export ne permettent pas de faire
des libs ?

Certainement. Mais j'imagine que même avec export, l'utilisation d'un
template exige plus qu'il n'y a dans la bibliothèque. (Bien que... avec
certains formats d'objet, il doit être possible de mettre toute
l'information nécessaire dans l'objet.)

Que permettent-ils de faire, alors ? juste un .o ? Et quelle est la
différence entre une lib et un .o ?

Un peu de nomenclature :
suffixe
type de fichier Unix Windows

objet classique .o .obj
objet dynamique .so .dll
bibliothèque .a .lib

objet classique :
Ce qui sort de la compilation, correspond en général à une
« module », ou en C++-speak, une unité de traduction. Mais en
général seulement -- je me suis déjà servi des systèmes où on
pouvait mettre plusieurs modules dans un seul objet.

Un objet est indivisible, on l'incorpore dans son programme, ou on
ne l'incorpore pas, mais on n'en prend jamais qu'une partie.

objet dynamique :
Le résultat d'une édition de liens d'un ou de plusieurs objets
classiques, pour en faire une entité indivisible dont l'édition de
liens ne se ferait qu'à l'execution.

bibliothèque :
Un ensemble d'objets, d'où l'éditeur de liens prend ceux qu'il lui
faut. La grande différence, par rapport aux deux précédants, c'est
précisement qu'elle est un ensemble, et qu'on n'en prend que les
éléments dont on a besoin.

Tout celà correspond à un concepte classique de la génération du
programme. Les templates n'y passent pas très bien : on peut,
conceptuellement, penser aux templates comme s'ils étaient des modèles
du code, et non du code même. L'instantation aurait donc lieu *avant*
l'édition de liens, pour en générer des modules supplémentaire. En tout
cas, les objets classiques, ainsi que les fichiers qui en dérivent (les
objets dynamiques et les bibliothèques) ne peuvent contenir que des
instantiations des templates, et non des templates mêmes.

Ça, c'est au niveau des fichiers. En général, si tu livres « une
bibliothèque », tu ne livres pas qu'un fichier bibliothèque -- tu livres
un ensemble de fichiers qui sert à l'utilisation de ta bibliothèque :
dans la schèma classique, typiquement, un fichier bibliothèque, des
fichiers d'en-tête (source) et de la documentation. À ce niveau-là, le
fait que la bibliothèque contient des templates ne change rien au niveau
du concepte -- il se peut qu'il y aurait d'autres types de fichiers à
livrer, mais de toute façon, c'est toujours un ensemble de fichiers que
tu livres. Sans export, l'implémentation des templates se trouve dans
les en-têtes, avec export, elle se trouve ailleurs, mais dans les deux
cas, il faut que tu livres l'implémentation des templates, parce que
plus que du code, c'est un modèle du code, et c'est l'utilisateur que le
vrai code serait généré.

J'avais cru comprendre qu'il etait possible de recreer ce .lib a
partir de la dll.

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

A priori, dans un objet dynamique, on a perdu l'information en ce qui
concerne la découpe originale en éléments. Or, ce qui caractèrise une
bibliothèque, c'est vraiment le fait que lors de l'édition de liens, on
n'en prend que ce dont on a besoin.

En fait tout est possible si on embarque tout le compilateur C++
dans le run-time (ce qui s'est fait pour des systemes lisp).

Certes. Mais je soupçonne qu'un compilateur C++ est moins
"embarquable" qu'un compilo Lisp.

J'imagine. De toute façon, je crois que le runtime de Lisp a besoin que
le compilateur y fasse partie ; ça fait en quelque sort partie de la
bibliothèque standard. Ce qui n'est pas le cas de C++.

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