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.
Loïc Joly wrote in message news:<41a39b55$0$3371$...
[...]
Il y a deux types de .lib :
Il y a surtout confusion entre des fichiers bibliothèque (.lib ou .a), et le concepte d'une bibliothèque en général. Quand tu livres une bibliothèque (même sans templates), tu ne livres pas qu'un fichier bibliothèque -- tu livres aussi des en-têtes (.h, .hpp, .hh...) et (j'espère) de la doc (.html, .pdf, .info, .dvi, .doc... le choix est énorme).
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.
Ça m'étonnerait un peu -- ce n'est pas le cas des .so d'Unix. Ce qui est (obligatoirement) présent, c'est assez d'information pour faire les liens : le nom « décoré » des fonctions, etc. À partir de ça, on pourrait récupérer le nom réel de la fonction ainsi que les types de ces paramètres. Mais non le type de rétour, ni (par exemple), la taille des classes, sans parler des membres données, des commentaires de documentation, etc., etc.
Maintenant, il existe des DLL spéciales (les DLL com, les DLL.NET) qui elles peuvent fournir plus d'info.
Tout à fait. Les formats objet modernes sont prèsque tous extensibles, de façon à ce qu'un compilateur peut y mettre toutes les informations supplémentaire qu'il veut. Dans la pratique, il n'y met que ce qu'il faut pour faire le travail en question.
-- 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:<41a39b55$0$3371$8fcfb975@news.wanadoo.fr>...
[...]
Il y a deux types de .lib :
Il y a surtout confusion entre des fichiers bibliothèque (.lib ou .a),
et le concepte d'une bibliothèque en général. Quand tu livres une
bibliothèque (même sans templates), tu ne livres pas qu'un fichier
bibliothèque -- tu livres aussi des en-têtes (.h, .hpp, .hh...) et
(j'espère) de la doc (.html, .pdf, .info, .dvi, .doc... le choix est
énorme).
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.
Ça m'étonnerait un peu -- ce n'est pas le cas des .so d'Unix. Ce qui est
(obligatoirement) présent, c'est assez d'information pour faire les
liens : le nom « décoré » des fonctions, etc. À partir de ça, on
pourrait récupérer le nom réel de la fonction ainsi que les types de ces
paramètres. Mais non le type de rétour, ni (par exemple), la taille des
classes, sans parler des membres données, des commentaires de
documentation, etc., etc.
Maintenant, il existe des DLL spéciales (les DLL com, les DLL.NET) qui
elles peuvent fournir plus d'info.
Tout à fait. Les formats objet modernes sont prèsque tous extensibles,
de façon à ce qu'un compilateur peut y mettre toutes les informations
supplémentaire qu'il veut. Dans la pratique, il n'y met que ce qu'il
faut pour faire le travail en question.
--
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:<41a39b55$0$3371$...
[...]
Il y a deux types de .lib :
Il y a surtout confusion entre des fichiers bibliothèque (.lib ou .a), et le concepte d'une bibliothèque en général. Quand tu livres une bibliothèque (même sans templates), tu ne livres pas qu'un fichier bibliothèque -- tu livres aussi des en-têtes (.h, .hpp, .hh...) et (j'espère) de la doc (.html, .pdf, .info, .dvi, .doc... le choix est énorme).
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.
Ça m'étonnerait un peu -- ce n'est pas le cas des .so d'Unix. Ce qui est (obligatoirement) présent, c'est assez d'information pour faire les liens : le nom « décoré » des fonctions, etc. À partir de ça, on pourrait récupérer le nom réel de la fonction ainsi que les types de ces paramètres. Mais non le type de rétour, ni (par exemple), la taille des classes, sans parler des membres données, des commentaires de documentation, etc., etc.
Maintenant, il existe des DLL spéciales (les DLL com, les DLL.NET) qui elles peuvent fournir plus d'info.
Tout à fait. Les formats objet modernes sont prèsque tous extensibles, de façon à ce qu'un compilateur peut y mettre toutes les informations supplémentaire qu'il veut. Dans la pratique, il n'y met que ce qu'il faut pour faire le travail en question.
-- 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
Matthieu Moy
writes:
Quand tu livres une bibliothèque (même sans templates), tu ne livres pas qu'un fichier bibliothèque -- tu livres aussi des en-têtes (.h, .hpp, .hh...) et (j'espère) de la doc (.html, .pdf, .info, .dvi, .doc... le choix est énorme).
Quand tu livres une bibliothèque à un développeur.
Quand tu la livre à l'utilisateur qui n'a besoin que du "runtime", le fichier bibliothèque est suffisant.
-- Matthieu
kanze@gabi-soft.fr writes:
Quand tu livres une bibliothèque (même sans templates), tu ne livres
pas qu'un fichier bibliothèque -- tu livres aussi des en-têtes (.h,
.hpp, .hh...) et (j'espère) de la doc (.html, .pdf, .info, .dvi,
.doc... le choix est énorme).
Quand tu livres une bibliothèque à un développeur.
Quand tu la livre à l'utilisateur qui n'a besoin que du "runtime", le
fichier bibliothèque est suffisant.
Quand tu livres une bibliothèque (même sans templates), tu ne livres pas qu'un fichier bibliothèque -- tu livres aussi des en-têtes (.h, .hpp, .hh...) et (j'espère) de la doc (.html, .pdf, .info, .dvi, .doc... le choix est énorme).
Quand tu livres une bibliothèque à un développeur.
Quand tu la livre à l'utilisateur qui n'a besoin que du "runtime", le fichier bibliothèque est suffisant.
-- Matthieu
Arnaud Meurgues
Loïc Joly wrote:
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.
On peut se lier statiquement à une dll ?
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.
Ah ? Ils ont une fonction d'includes précompilés, alors ?
Maintenant, il existe des DLL spéciales (les DLL com, les DLL.NET) qui elles peuvent fournir plus d'info.
Pour les dll .NET, c'est clair que c'est complètement différent (d'ailleurs, moi, j'aurais changé l'extension, mais bon).
-- Arnaud (Supprimez les geneurs pour me répondre)
Loïc Joly wrote:
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.
On peut se lier statiquement à une dll ?
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.
Ah ? Ils ont une fonction d'includes précompilés, alors ?
Maintenant, il existe des DLL spéciales (les DLL com, les DLL.NET) qui
elles peuvent fournir plus d'info.
Pour les dll .NET, c'est clair que c'est complètement différent
(d'ailleurs, moi, j'aurais changé l'extension, mais bon).
--
Arnaud
(Supprimez les geneurs pour me répondre)
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.
On peut se lier statiquement à une dll ?
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.
Ah ? Ils ont une fonction d'includes précompilés, alors ?
Maintenant, il existe des DLL spéciales (les DLL com, les DLL.NET) qui elles peuvent fournir plus d'info.
Pour les dll .NET, c'est clair que c'est complètement différent (d'ailleurs, moi, j'aurais changé l'extension, mais bon).
-- Arnaud (Supprimez les geneurs pour me répondre)
Arnaud Meurgues
wrote:
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é.
Voilà. On arrive à la question que je me pose. Sous quelle forme est livré le modèle du code. Je pensais, naïvement sans doute, que celui-ci était embarqué dans le .o (et du coup, il aurait pu tout aussi bien être embarqué dans un .a qui n'est qu'une archive de .o). Ce n'est pas le cas ?
-- Arnaud (Supprimez les geneurs pour me répondre)
kanze@gabi-soft.fr wrote:
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é.
Voilà. On arrive à la question que je me pose. Sous quelle forme est
livré le modèle du code. Je pensais, naïvement sans doute, que celui-ci
était embarqué dans le .o (et du coup, il aurait pu tout aussi bien être
embarqué dans un .a qui n'est qu'une archive de .o). Ce n'est pas le cas ?
--
Arnaud
(Supprimez les geneurs pour me répondre)
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é.
Voilà. On arrive à la question que je me pose. Sous quelle forme est livré le modèle du code. Je pensais, naïvement sans doute, que celui-ci était embarqué dans le .o (et du coup, il aurait pu tout aussi bien être embarqué dans un .a qui n'est qu'une archive de .o). Ce n'est pas le cas ?
-- Arnaud (Supprimez les geneurs pour me répondre)
adebaene
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).
Arnaud
Arnaud Meurgues <arnaud@meurgues.non.fr.invalid> wrote in message news:<41a30ccb$0$6702$626a14ce@news.free.fr>...
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).
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).
Arnaud
Arnaud Meurgues
Arnaud Debaene wrote:
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).
Merci.
-- Arnaud (Supprimez les geneurs pour me répondre)
Arnaud Debaene wrote:
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).
Merci.
--
Arnaud
(Supprimez les geneurs pour me répondre)
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).
Merci.
-- Arnaud (Supprimez les geneurs pour me répondre)
Jean-Marc Bourguet
Arnaud Meurgues writes:
wrote:
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é.
Voilà. On arrive à la question que je me pose. Sous quelle forme est livré le modèle du code. Je pensais, naïvement sans doute, que celui-ci était embarqué dans le .o (et du coup, il aurait pu tout aussi bien être embarqué dans un .a qui n'est qu'une archive de .o). Ce n'est pas le cas ?
Rien dans la norme indique comment c'est fait.
como et Intel demandent pour le moment que le source soit fournit. David a dit que le front-end d'EDG avait l'interface pour que ce ne soit pas necessaire.
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
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é.
Voilà. On arrive à la question que je me pose. Sous quelle forme est
livré le modèle du code. Je pensais, naïvement sans doute, que
celui-ci était embarqué dans le .o (et du coup, il aurait pu tout
aussi bien être embarqué dans un .a qui n'est qu'une archive de
.o). Ce n'est pas le cas ?
Rien dans la norme indique comment c'est fait.
como et Intel demandent pour le moment que le source soit fournit.
David a dit que le front-end d'EDG avait l'interface pour que ce ne
soit pas necessaire.
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
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é.
Voilà. On arrive à la question que je me pose. Sous quelle forme est livré le modèle du code. Je pensais, naïvement sans doute, que celui-ci était embarqué dans le .o (et du coup, il aurait pu tout aussi bien être embarqué dans un .a qui n'est qu'une archive de .o). Ce n'est pas le cas ?
Rien dans la norme indique comment c'est fait.
como et Intel demandent pour le moment que le source soit fournit. David a dit que le front-end d'EDG avait l'interface pour que ce ne soit pas necessaire.
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
Jean-Marc Bourguet
(Arnaud Debaene) writes:
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).
J'ai un pb. Si j'ai bien compris on ne peut pas changer la DLL apres avoir lie? Si oui qu'est-ce qui empeche les offsets d'avoir change?
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
Arnaud Meurgues <arnaud@meurgues.non.fr.invalid> wrote in message
news:<41a30ccb$0$6702$626a14ce@news.free.fr>...
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).
J'ai un pb. Si j'ai bien compris on ne peut pas changer la DLL apres
avoir lie? Si oui qu'est-ce qui empeche les offsets d'avoir change?
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
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).
J'ai un pb. Si j'ai bien compris on ne peut pas changer la DLL apres avoir lie? Si oui qu'est-ce qui empeche les offsets d'avoir change?
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
Arnaud Meurgues
Jean-Marc Bourguet wrote:
livré le modèle du code. Je pensais, naïvement sans doute, que celui-ci était embarqué dans le .o (et du coup, il aurait pu tout aussi bien être embarqué dans un .a qui n'est qu'une archive de .o). Ce n'est pas le cas ? Rien dans la norme indique comment c'est fait.
Certes. La norme n'impose pas grand chose sur l'implémentation.
como et Intel demandent pour le moment que le source soit fournit.
C'est ce qui m'étonne le plus.
David a dit que le front-end d'EDG avait l'interface pour que ce ne soit pas necessaire.
Ça me paraît plus raisonnable. Et dans ce cas, comment est-ce fait ?
-- Arnaud (Supprimez les geneurs pour me répondre)
Jean-Marc Bourguet wrote:
livré le modèle du code. Je pensais, naïvement sans doute, que
celui-ci était embarqué dans le .o (et du coup, il aurait pu tout
aussi bien être embarqué dans un .a qui n'est qu'une archive de
.o). Ce n'est pas le cas ?
Rien dans la norme indique comment c'est fait.
Certes. La norme n'impose pas grand chose sur l'implémentation.
como et Intel demandent pour le moment que le source soit fournit.
C'est ce qui m'étonne le plus.
David a dit que le front-end d'EDG avait l'interface pour que ce ne
soit pas necessaire.
Ça me paraît plus raisonnable. Et dans ce cas, comment est-ce fait ?
--
Arnaud
(Supprimez les geneurs pour me répondre)
livré le modèle du code. Je pensais, naïvement sans doute, que celui-ci était embarqué dans le .o (et du coup, il aurait pu tout aussi bien être embarqué dans un .a qui n'est qu'une archive de .o). Ce n'est pas le cas ? Rien dans la norme indique comment c'est fait.
Certes. La norme n'impose pas grand chose sur l'implémentation.
como et Intel demandent pour le moment que le source soit fournit.
C'est ce qui m'étonne le plus.
David a dit que le front-end d'EDG avait l'interface pour que ce ne soit pas necessaire.
Ça me paraît plus raisonnable. Et dans ce cas, comment est-ce fait ?
-- Arnaud (Supprimez les geneurs pour me répondre)
Jean-Marc Bourguet
Arnaud Meurgues writes:
Jean-Marc Bourguet wrote:
livré le modèle du code. Je pensais, naïvement sans doute, que celui-ci était embarqué dans le .o (et du coup, il aurait pu tout aussi bien être embarqué dans un .a qui n'est qu'une archive de .o). Ce n'est pas le cas ? Rien dans la norme indique comment c'est fait.
Certes. La norme n'impose pas grand chose sur l'implémentation.
como et Intel demandent pour le moment que le source soit fournit.
C'est ce qui m'étonne le plus.
De la part de como, ca ne m'etonne pas du tout. C'est un compilateur qui genere du C puis qui utilise le compilo C de la platerforme pour faire l'objet. Ca ne correspond pas du tout a son architecture de commencer a jouer a des astuces sur les fichiers objets.
Dans le cas d'Intel, c'est la premiere version qui fournit export. Je suppose qu'ils essayent d'abord de le faire fonctionner avant de fournir ce genre d'optimisation. De plus leur compilateur est a la fois pour Linux et pour Windows. Si je pense que elf a les possibilites qu'il faut pour que ce soit possible de mettre dans un .o les info necessaires a l'instanciation de template exporte, je ne connais pas assez .lib pour savoir si c'est possible. Ce que je me souviens de DOS me laisse penser que non, mais mes souvenirs ne sont pas si nets que ca et le format a pu evoluer.
David a dit que le front-end d'EDG avait l'interface pour que ce ne soit pas necessaire.
Ça me paraît plus raisonnable. Et dans ce cas, comment est-ce fait ?
Je ne suis pas utilisateur d'EDG. Une possibilite est de fournir la possibilite d'enregistrer des callbacks pour sauver et restaurer l'etat necessaire.
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
livré le modèle du code. Je pensais, naïvement sans doute, que
celui-ci était embarqué dans le .o (et du coup, il aurait pu tout
aussi bien être embarqué dans un .a qui n'est qu'une archive de
.o). Ce n'est pas le cas ?
Rien dans la norme indique comment c'est fait.
Certes. La norme n'impose pas grand chose sur l'implémentation.
como et Intel demandent pour le moment que le source soit fournit.
C'est ce qui m'étonne le plus.
De la part de como, ca ne m'etonne pas du tout. C'est un compilateur
qui genere du C puis qui utilise le compilo C de la platerforme pour
faire l'objet. Ca ne correspond pas du tout a son architecture de
commencer a jouer a des astuces sur les fichiers objets.
Dans le cas d'Intel, c'est la premiere version qui fournit export. Je
suppose qu'ils essayent d'abord de le faire fonctionner avant de
fournir ce genre d'optimisation. De plus leur compilateur est a la
fois pour Linux et pour Windows. Si je pense que elf a les
possibilites qu'il faut pour que ce soit possible de mettre dans un .o
les info necessaires a l'instanciation de template exporte, je ne
connais pas assez .lib pour savoir si c'est possible. Ce que je me
souviens de DOS me laisse penser que non, mais mes souvenirs ne sont
pas si nets que ca et le format a pu evoluer.
David a dit que le front-end d'EDG avait l'interface pour que ce
ne soit pas necessaire.
Ça me paraît plus raisonnable. Et dans ce cas, comment est-ce fait ?
Je ne suis pas utilisateur d'EDG. Une possibilite est de fournir la
possibilite d'enregistrer des callbacks pour sauver et restaurer
l'etat necessaire.
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
livré le modèle du code. Je pensais, naïvement sans doute, que celui-ci était embarqué dans le .o (et du coup, il aurait pu tout aussi bien être embarqué dans un .a qui n'est qu'une archive de .o). Ce n'est pas le cas ? Rien dans la norme indique comment c'est fait.
Certes. La norme n'impose pas grand chose sur l'implémentation.
como et Intel demandent pour le moment que le source soit fournit.
C'est ce qui m'étonne le plus.
De la part de como, ca ne m'etonne pas du tout. C'est un compilateur qui genere du C puis qui utilise le compilo C de la platerforme pour faire l'objet. Ca ne correspond pas du tout a son architecture de commencer a jouer a des astuces sur les fichiers objets.
Dans le cas d'Intel, c'est la premiere version qui fournit export. Je suppose qu'ils essayent d'abord de le faire fonctionner avant de fournir ce genre d'optimisation. De plus leur compilateur est a la fois pour Linux et pour Windows. Si je pense que elf a les possibilites qu'il faut pour que ce soit possible de mettre dans un .o les info necessaires a l'instanciation de template exporte, je ne connais pas assez .lib pour savoir si c'est possible. Ce que je me souviens de DOS me laisse penser que non, mais mes souvenirs ne sont pas si nets que ca et le format a pu evoluer.
David a dit que le front-end d'EDG avait l'interface pour que ce ne soit pas necessaire.
Ça me paraît plus raisonnable. Et dans ce cas, comment est-ce fait ?
Je ne suis pas utilisateur d'EDG. Une possibilite est de fournir la possibilite d'enregistrer des callbacks pour sauver et restaurer l'etat necessaire.
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
