Bibliotheques de classes non normalisé ?

Le
jeremie fouche
Bonsoir

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 ?

Merci pour vos éclaircissements
--
Jérémie
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Fabien LE LEZ
Le #307208
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
Le #307207
jeremie fouche
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
Le #307178
On May 22, 8:12 pm, 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.


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
Le #307177
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
Le #307176

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
Le #307175
On May 22, 8:12 pm, Fabien LE LEZ ...plein d'explications...



Merci beaucoup à tous, c'est plus clair pour moi
--
Jérémie

Loïc Joly
Le #307174
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

Publicité
Poster une réponse
Anonyme