Je me pose une question depuis un moment sur les bibliothèques de
classes C++ (DLL / lib) par rapport aux bibliothèques de fonctions C (en
tout cas sous Windows, je ne connais pas *nix) :
Les bibliothèques C sont accessibles via n'importes quels compilateurs.
Il suffit de linker et hop, ça marche, Que cette bibliothèques ait été
compilé via gcc, Visual, ...
Par contre, pour le C++, ça se corse, il faut compiler la bibliothèque
avec le compilateur avec lequel on souhaite utiliser la bibliothèque. Je
suppose que le problème vient de la maniere dont le compilateur nomme
les méthodes / classes :
ex pour wxWindows : _ZT9wxAppBase par exemple pour la classe wxAppBase
je suppose.
La question est donc la suivante : N'y a t il pas une norme C++ qui
impose le nom décoré ? Chaque compilateur fait comme il veut ?
Pourquoi ne pas permettre d'accéder à une bibliothèque C++ pour tout le
monde ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fabien LE LEZ
On Tue, 22 May 2007 20:00:37 +0200, jeremie fouche :
N'y a t il pas une norme C++ qui impose le nom décoré ?
Non. En fait, je ne suis même pas sûr qu'il y ait une telle norme pour C.
Les bibliothèques C sont accessibles via n'importes quels compilateurs. Il suffit de linker et hop, ça marche, Que cette bibliothèques ait été compilé via gcc, Visual, ...
Il se trouve que l'auteur de gcc-Windows a décidé d'employer le même format binaire pour les .lib que Visual. Idem pour le compilo Intel, d'ailleurs, je crois bien. Ça n'a rien d'une norme, c'est juste une décision de l'auteur du compilo. Si je ne m'abuse, le format binaire de Borland C++, même en C, est incompatible avec celui de Visual.
Pour les DLL, il s'agit d'un format dicté par Microsoft, et auquel tous les compilos doivent se conformer. Là encore, rien à voir avec une quelconque norme ISO-C.
On Tue, 22 May 2007 20:00:37 +0200, jeremie fouche <jfouche@voila.fr>:
N'y a t il pas une norme C++ qui impose le nom décoré ?
Non.
En fait, je ne suis même pas sûr qu'il y ait une telle norme pour C.
Les bibliothèques C sont accessibles via n'importes quels compilateurs.
Il suffit de linker et hop, ça marche, Que cette bibliothèques ait été
compilé via gcc, Visual, ...
Il se trouve que l'auteur de gcc-Windows a décidé d'employer le même
format binaire pour les .lib que Visual. Idem pour le compilo Intel,
d'ailleurs, je crois bien. Ça n'a rien d'une norme, c'est juste une
décision de l'auteur du compilo.
Si je ne m'abuse, le format binaire de Borland C++, même en C, est
incompatible avec celui de Visual.
Pour les DLL, il s'agit d'un format dicté par Microsoft, et auquel
tous les compilos doivent se conformer. Là encore, rien à voir avec
une quelconque norme ISO-C.
On Tue, 22 May 2007 20:00:37 +0200, jeremie fouche :
N'y a t il pas une norme C++ qui impose le nom décoré ?
Non. En fait, je ne suis même pas sûr qu'il y ait une telle norme pour C.
Les bibliothèques C sont accessibles via n'importes quels compilateurs. Il suffit de linker et hop, ça marche, Que cette bibliothèques ait été compilé via gcc, Visual, ...
Il se trouve que l'auteur de gcc-Windows a décidé d'employer le même format binaire pour les .lib que Visual. Idem pour le compilo Intel, d'ailleurs, je crois bien. Ça n'a rien d'une norme, c'est juste une décision de l'auteur du compilo. Si je ne m'abuse, le format binaire de Borland C++, même en C, est incompatible avec celui de Visual.
Pour les DLL, il s'agit d'un format dicté par Microsoft, et auquel tous les compilos doivent se conformer. Là encore, rien à voir avec une quelconque norme ISO-C.
Jean-Marc Bourguet
jeremie fouche writes:
La question est donc la suivante : N'y a t il pas une norme C++ qui impose le nom décoré ? Chaque compilateur fait comme il veut ? Pourquoi ne pas permettre d'accéder à une bibliothèque C++ pour tout le monde ?
Voir les questions 7.1 et 7.2 de la FAQ http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/
-- 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
jeremie fouche <jfouche@voila.fr> writes:
La question est donc la suivante : N'y a t il pas une norme C++ qui impose
le nom décoré ? Chaque compilateur fait comme il veut ?
Pourquoi ne pas permettre d'accéder à une bibliothèque C++ pour tout le
monde ?
Voir les questions 7.1 et 7.2 de la FAQ
http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/
--
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
La question est donc la suivante : N'y a t il pas une norme C++ qui impose le nom décoré ? Chaque compilateur fait comme il veut ? Pourquoi ne pas permettre d'accéder à une bibliothèque C++ pour tout le monde ?
Voir les questions 7.1 et 7.2 de la FAQ http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/
-- 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
James Kanze
On May 22, 8:12 pm, Fabien LE LEZ wrote:
On Tue, 22 May 2007 20:00:37 +0200, jeremie fouche :
N'y a t il pas une norme C++ qui impose le nom décoré ?
Non. En fait, je ne suis même pas sûr qu'il y ait une telle norme pour C.
Oui et non. La plupart des vendeurs en ont défini une pour leur plateformes : il y a donc bien une norme pour l'API C sous Solaris/Sparc, etc. Évidemment, un vendeur de compilateur C n'est pas obligé d'y tenir, sauf pour les appels système, mais dans la pratique, le C est assez simple pour qu'il y a peu de choses à varier, et tous les compilateurs s'alignent sans trop de problème.
Note bien que ça ne vaut pas que pour les vendeurs différents. J'ai vu au moins trois API différentes avec de différentes versions de Sun CC, alors que le C que je pourrais linker le C compiler il y a vingt ans sans problème.
Le problème de base, évidemment, c'est que pour l'interopérabilité, il y a beaucoup plus de choses à respecter en C++. En C, ça se limite plus ou moins aux questions de padding (oui ou non) et comment passer les paramètres et les valeurs de retour. (Ça peut toucher aussi des représentations des types non supportés directement par le hardware -- je me rappelle un changement dans l'ordre des octets dans un long entre deux versions du compilateur C de Microsoft -- mais aujourd'hui, je crois que le problème se limite à long double.) En C++, il y a aussi toute l'organisation d'une classe en mémoire : la structure de la vtbl, comment accéder aux bases virtuelles, les type_info, etc.
Et évidemment, la question de la décoration n'y est pour rien. Au contraire, les compilateurs qui utilise des organisations en mémoire différentes ont tout intérêt à utiliser une décoration différente aussi, pour qu'on ait une erreur lors de l'édition des liens, plutôt qu'un comportement bizarre lors de l'exécution.
Les bibliothèques C sont accessibles via n'importes quels compilateurs. Il suffit de linker et hop, ça marche, Que cette bibliothèques ait été compilé via gcc, Visual, ...
Il se trouve que l'auteur de gcc-Windows a décidé d'employer le même format binaire pour les .lib que Visual. Idem pour le compilo Intel, d'ailleurs, je crois bien. Ça n'a rien d'une norme, c'est juste une décision de l'auteur du compilo.
Dans la pratique, sinon officiellement, l'API utilisée par VC++ est bien une norme pour Windows.
Quand Intel a développé l'Itanium, ils ont voulu éviter ce genre de problème, et ils ont défini un API C++ dès le départ ; tous les compilateurs Itanium s'y alignent (et g++ l'a adopté généralement, je crois, pour toutes ces plateformes).
Si je ne m'abuse, le format binaire de Borland C++, même en C, est incompatible avec celui de Visual.
Pour les DLL, il s'agit d'un format dicté par Microsoft, et auquel tous les compilos doivent se conformer. Là encore, rien à voir avec une quelconque norme ISO-C.
Un DLL n'est au fond autre chose qu'un format objet (et non bibliothèque, malgré son nom). En tant que tel, le format du fichier, et où on trouve des informations là-dedans, et bien spécifié, de même qu'il l'est sous Solaris pour les .so. En revanche, sous Solaris au moins, ce n'est pas une garantie quant à l'organisation d'une classe en mémoire, et je suis relativement certain qu'on pourrait créer des DLL qui ne marche qu'avec un compilateur donné.
-- James Kanze (GABI Software) email: 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
On May 22, 8:12 pm, Fabien LE LEZ <grams...@gramster.com> wrote:
On Tue, 22 May 2007 20:00:37 +0200, jeremie fouche <jfou...@voila.fr>:
N'y a t il pas une norme C++ qui impose le nom décoré ?
Non.
En fait, je ne suis même pas sûr qu'il y ait une telle norme pour C.
Oui et non. La plupart des vendeurs en ont défini une pour leur
plateformes : il y a donc bien une norme pour l'API C sous
Solaris/Sparc, etc. Évidemment, un vendeur de compilateur C
n'est pas obligé d'y tenir, sauf pour les appels système, mais
dans la pratique, le C est assez simple pour qu'il y a peu de
choses à varier, et tous les compilateurs s'alignent sans trop
de problème.
Note bien que ça ne vaut pas que pour les vendeurs différents.
J'ai vu au moins trois API différentes avec de différentes
versions de Sun CC, alors que le C que je pourrais linker le C
compiler il y a vingt ans sans problème.
Le problème de base, évidemment, c'est que pour
l'interopérabilité, il y a beaucoup plus de choses à respecter
en C++. En C, ça se limite plus ou moins aux questions de
padding (oui ou non) et comment passer les paramètres et les
valeurs de retour. (Ça peut toucher aussi des représentations
des types non supportés directement par le hardware -- je me
rappelle un changement dans l'ordre des octets dans un long
entre deux versions du compilateur C de Microsoft -- mais
aujourd'hui, je crois que le problème se limite à long double.)
En C++, il y a aussi toute l'organisation d'une classe en
mémoire : la structure de la vtbl, comment accéder aux bases
virtuelles, les type_info, etc.
Et évidemment, la question de la décoration n'y est pour rien.
Au contraire, les compilateurs qui utilise des organisations en
mémoire différentes ont tout intérêt à utiliser une décoration
différente aussi, pour qu'on ait une erreur lors de l'édition
des liens, plutôt qu'un comportement bizarre lors de
l'exécution.
Les bibliothèques C sont accessibles via n'importes quels compilateurs.
Il suffit de linker et hop, ça marche, Que cette bibliothèques ait été
compilé via gcc, Visual, ...
Il se trouve que l'auteur de gcc-Windows a décidé d'employer le même
format binaire pour les .lib que Visual. Idem pour le compilo Intel,
d'ailleurs, je crois bien. Ça n'a rien d'une norme, c'est juste une
décision de l'auteur du compilo.
Dans la pratique, sinon officiellement, l'API utilisée par VC++
est bien une norme pour Windows.
Quand Intel a développé l'Itanium, ils ont voulu éviter ce genre
de problème, et ils ont défini un API C++ dès le départ ; tous
les compilateurs Itanium s'y alignent (et g++ l'a adopté
généralement, je crois, pour toutes ces plateformes).
Si je ne m'abuse, le format binaire de Borland C++, même en C, est
incompatible avec celui de Visual.
Pour les DLL, il s'agit d'un format dicté par Microsoft, et auquel
tous les compilos doivent se conformer. Là encore, rien à voir avec
une quelconque norme ISO-C.
Un DLL n'est au fond autre chose qu'un format objet (et non
bibliothèque, malgré son nom). En tant que tel, le format du
fichier, et où on trouve des informations là-dedans, et bien
spécifié, de même qu'il l'est sous Solaris pour les .so. En
revanche, sous Solaris au moins, ce n'est pas une garantie quant
à l'organisation d'une classe en mémoire, et je suis
relativement certain qu'on pourrait créer des DLL qui ne marche
qu'avec un compilateur donné.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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
On Tue, 22 May 2007 20:00:37 +0200, jeremie fouche :
N'y a t il pas une norme C++ qui impose le nom décoré ?
Non. En fait, je ne suis même pas sûr qu'il y ait une telle norme pour C.
Oui et non. La plupart des vendeurs en ont défini une pour leur plateformes : il y a donc bien une norme pour l'API C sous Solaris/Sparc, etc. Évidemment, un vendeur de compilateur C n'est pas obligé d'y tenir, sauf pour les appels système, mais dans la pratique, le C est assez simple pour qu'il y a peu de choses à varier, et tous les compilateurs s'alignent sans trop de problème.
Note bien que ça ne vaut pas que pour les vendeurs différents. J'ai vu au moins trois API différentes avec de différentes versions de Sun CC, alors que le C que je pourrais linker le C compiler il y a vingt ans sans problème.
Le problème de base, évidemment, c'est que pour l'interopérabilité, il y a beaucoup plus de choses à respecter en C++. En C, ça se limite plus ou moins aux questions de padding (oui ou non) et comment passer les paramètres et les valeurs de retour. (Ça peut toucher aussi des représentations des types non supportés directement par le hardware -- je me rappelle un changement dans l'ordre des octets dans un long entre deux versions du compilateur C de Microsoft -- mais aujourd'hui, je crois que le problème se limite à long double.) En C++, il y a aussi toute l'organisation d'une classe en mémoire : la structure de la vtbl, comment accéder aux bases virtuelles, les type_info, etc.
Et évidemment, la question de la décoration n'y est pour rien. Au contraire, les compilateurs qui utilise des organisations en mémoire différentes ont tout intérêt à utiliser une décoration différente aussi, pour qu'on ait une erreur lors de l'édition des liens, plutôt qu'un comportement bizarre lors de l'exécution.
Les bibliothèques C sont accessibles via n'importes quels compilateurs. Il suffit de linker et hop, ça marche, Que cette bibliothèques ait été compilé via gcc, Visual, ...
Il se trouve que l'auteur de gcc-Windows a décidé d'employer le même format binaire pour les .lib que Visual. Idem pour le compilo Intel, d'ailleurs, je crois bien. Ça n'a rien d'une norme, c'est juste une décision de l'auteur du compilo.
Dans la pratique, sinon officiellement, l'API utilisée par VC++ est bien une norme pour Windows.
Quand Intel a développé l'Itanium, ils ont voulu éviter ce genre de problème, et ils ont défini un API C++ dès le départ ; tous les compilateurs Itanium s'y alignent (et g++ l'a adopté généralement, je crois, pour toutes ces plateformes).
Si je ne m'abuse, le format binaire de Borland C++, même en C, est incompatible avec celui de Visual.
Pour les DLL, il s'agit d'un format dicté par Microsoft, et auquel tous les compilos doivent se conformer. Là encore, rien à voir avec une quelconque norme ISO-C.
Un DLL n'est au fond autre chose qu'un format objet (et non bibliothèque, malgré son nom). En tant que tel, le format du fichier, et où on trouve des informations là-dedans, et bien spécifié, de même qu'il l'est sous Solaris pour les .so. En revanche, sous Solaris au moins, ce n'est pas une garantie quant à l'organisation d'une classe en mémoire, et je suis relativement certain qu'on pourrait créer des DLL qui ne marche qu'avec un compilateur donné.
-- James Kanze (GABI Software) email: 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
Alain Gaillard
Si je ne m'abuse, le format binaire de Borland C++, même en C, est incompatible avec celui de Visual.
Oui. En l'occurence, ce n'est pas une question de décoration de noms de fonction puisque le problème est le même en C. Il se trouve que Microsoft a choisi le format COFF pour les fichiers objets. Borland qui ne peut rien faire convenablement a choisi le format OMF, ce qui pose des problème sans fins. Bien sûr les petits malins de Borland vont te dire qu'il y a l'utilitaire coff2omf pour convertir. Mais ce qu'ils ne disent surtout pas, c'est que des informations sont perdues dans la grande majorité des cas et qu'utiliser des .obj ou donc des .lib sous Borland mais compilés sous Kro$oft est souvent impossible.
-- Alain
Si je ne m'abuse, le format binaire de Borland C++, même en C, est
incompatible avec celui de Visual.
Oui.
En l'occurence, ce n'est pas une question de décoration de noms de
fonction puisque le problème est le même en C.
Il se trouve que Microsoft a choisi le format COFF pour les fichiers
objets.
Borland qui ne peut rien faire convenablement a choisi le format OMF, ce
qui pose des problème sans fins.
Bien sûr les petits malins de Borland vont te dire qu'il y a l'utilitaire
coff2omf pour convertir.
Mais ce qu'ils ne disent surtout pas, c'est que des informations sont
perdues dans la grande majorité des cas et qu'utiliser des .obj ou donc
des .lib sous Borland mais compilés sous Kro$oft est souvent impossible.
Si je ne m'abuse, le format binaire de Borland C++, même en C, est incompatible avec celui de Visual.
Oui. En l'occurence, ce n'est pas une question de décoration de noms de fonction puisque le problème est le même en C. Il se trouve que Microsoft a choisi le format COFF pour les fichiers objets. Borland qui ne peut rien faire convenablement a choisi le format OMF, ce qui pose des problème sans fins. Bien sûr les petits malins de Borland vont te dire qu'il y a l'utilitaire coff2omf pour convertir. Mais ce qu'ils ne disent surtout pas, c'est que des informations sont perdues dans la grande majorité des cas et qu'utiliser des .obj ou donc des .lib sous Borland mais compilés sous Kro$oft est souvent impossible.
-- Alain
Mathias Gaunard
Je suppose que le problème vient de la maniere dont le compilateur nomme les méthodes / classes : ex pour wxWindows : _ZT9wxAppBase par exemple pour la classe wxAppBase je suppose.
Pas seulement. Certaines choses, comme par exemple les exceptions, peuvent être implémentées de différentes manières, ce qui résulte en des ABIs différents, et cela même avec un même compilateur dans des versions différentes.
Je
suppose que le problème vient de la maniere dont le compilateur nomme
les méthodes / classes :
ex pour wxWindows : _ZT9wxAppBase par exemple pour la classe wxAppBase
je suppose.
Pas seulement.
Certaines choses, comme par exemple les exceptions, peuvent être
implémentées de différentes manières, ce qui résulte en des ABIs
différents, et cela même avec un même compilateur dans des versions
différentes.
Je suppose que le problème vient de la maniere dont le compilateur nomme les méthodes / classes : ex pour wxWindows : _ZT9wxAppBase par exemple pour la classe wxAppBase je suppose.
Pas seulement. Certaines choses, comme par exemple les exceptions, peuvent être implémentées de différentes manières, ce qui résulte en des ABIs différents, et cela même avec un même compilateur dans des versions différentes.
jeremie fouche
On May 22, 8:12 pm, Fabien LE LEZ wrote: ...plein d'explications...
Merci beaucoup à tous, c'est plus clair pour moi -- Jérémie
On May 22, 8:12 pm, Fabien LE LEZ <grams...@gramster.com> wrote:
...plein d'explications...
Merci beaucoup à tous, c'est plus clair pour moi
--
Jérémie
On May 22, 8:12 pm, Fabien LE LEZ wrote: ...plein d'explications...
Merci beaucoup à tous, c'est plus clair pour moi -- Jérémie
Loïc Joly
Le problème de base, évidemment, c'est que pour l'interopérabilité, il y a beaucoup plus de choses à respecter en C++. En C, ça se limite plus ou moins aux questions de padding (oui ou non) et comment passer les paramètres et les valeurs de retour. (Ça peut toucher aussi des représentations des types non supportés directement par le hardware -- je me rappelle un changement dans l'ordre des octets dans un long entre deux versions du compilateur C de Microsoft -- mais aujourd'hui, je crois que le problème se limite à long double.) En C++, il y a aussi toute l'organisation d'une classe en mémoire : la structure de la vtbl, comment accéder aux bases virtuelles, les type_info, etc.
J'ai l'impression que les problèmes d'implémentations de bibliothèque standard sont bien plus prépondérants en C++ (ne serait-ce que par la richesse accrue), mais peuvent aussi arriver il me semble en C.
Je m'étonne de ne pas avoir entendu parler par exemple de FILE* qui posent problèmes quand créés par un compilateur et utilisés par un autre. Ou d'un size_t qui ne serait pas le même. Peut-être que l'ABI spécifie aussi ce genre de choses. Ou peut-être est-ce parce que je n'ai jamais programmé en C que ce problème ne m'a pas été reporté.
-- Loïc
Le problème de base, évidemment, c'est que pour
l'interopérabilité, il y a beaucoup plus de choses à respecter
en C++. En C, ça se limite plus ou moins aux questions de
padding (oui ou non) et comment passer les paramètres et les
valeurs de retour. (Ça peut toucher aussi des représentations
des types non supportés directement par le hardware -- je me
rappelle un changement dans l'ordre des octets dans un long
entre deux versions du compilateur C de Microsoft -- mais
aujourd'hui, je crois que le problème se limite à long double.)
En C++, il y a aussi toute l'organisation d'une classe en
mémoire : la structure de la vtbl, comment accéder aux bases
virtuelles, les type_info, etc.
J'ai l'impression que les problèmes d'implémentations de bibliothèque
standard sont bien plus prépondérants en C++ (ne serait-ce que par la
richesse accrue), mais peuvent aussi arriver il me semble en C.
Je m'étonne de ne pas avoir entendu parler par exemple de FILE* qui
posent problèmes quand créés par un compilateur et utilisés par un
autre. Ou d'un size_t qui ne serait pas le même. Peut-être que l'ABI
spécifie aussi ce genre de choses. Ou peut-être est-ce parce que je n'ai
jamais programmé en C que ce problème ne m'a pas été reporté.
Le problème de base, évidemment, c'est que pour l'interopérabilité, il y a beaucoup plus de choses à respecter en C++. En C, ça se limite plus ou moins aux questions de padding (oui ou non) et comment passer les paramètres et les valeurs de retour. (Ça peut toucher aussi des représentations des types non supportés directement par le hardware -- je me rappelle un changement dans l'ordre des octets dans un long entre deux versions du compilateur C de Microsoft -- mais aujourd'hui, je crois que le problème se limite à long double.) En C++, il y a aussi toute l'organisation d'une classe en mémoire : la structure de la vtbl, comment accéder aux bases virtuelles, les type_info, etc.
J'ai l'impression que les problèmes d'implémentations de bibliothèque standard sont bien plus prépondérants en C++ (ne serait-ce que par la richesse accrue), mais peuvent aussi arriver il me semble en C.
Je m'étonne de ne pas avoir entendu parler par exemple de FILE* qui posent problèmes quand créés par un compilateur et utilisés par un autre. Ou d'un size_t qui ne serait pas le même. Peut-être que l'ABI spécifie aussi ce genre de choses. Ou peut-être est-ce parce que je n'ai jamais programmé en C que ce problème ne m'a pas été reporté.
