Posté par gaaaaaAab .
En réponse au journal C(++) ?.
Évalué à 6.
Quel genre de portabilité ? C++ est très portable.
ça dépend. Si tu n'utilises toujours le même compilo sur toutes les plate formes, ça ira. Par contre, si tu utilises le compilo de Sun sur Solaris, le compilo d'HP sur HP-UX, g++ sur Linux, etc ... il vaut mieux ne pas utiliser les fonctionnalités trop récentes, parce qu'elles risquent de n'être supportées que par g++.
En quoi c'est pénible ? Il y a des bibliothèques qui font la conversion des noms de symboles pour toi.
je ne parlais pas de l'interprétation des symboles manglés pour qu'ils soient lisibles par un humain (nm -C !!) mais des problèmes d'intégration au runtime.
Le mangling n'étant pas standardisé, chaque compilo utilise le sien propre. Il n'est pas imaginable de linker deux libs binaires produites par deux compilos différents. Si tu compiles tout toi même, pas de problème. Par contre, si tu link sur des libraires externes, en plus de la version de la lib, tu dois gérer un paramètre de dépendance supplémentaire. Eventuellement, si tu récupères une lib binaire dont tu n'as pas les sources, tu te retrouves contraint à l'utilisation du compilateur qui a servi à générer cette lib.
Pire, deux versions différentes d'une même suite de compilation peuvent être incompatibles entre elles (c'est le cas de g++, qui pète régulièrement la compatibilité du mangling).
Côté mise en prod, ça peut aussi être un joyeux boxon. Pour peu que l'infrastructure technique ne soient pas complètement bien contrôlée, et que plusieurs services interviennent ...
tu peux toujours utiliser extern "C" pour exporter une interface plus « simple ».
oui, tu peux (en fait t'as pas le choix), mais c'est particulièrement pas objet, et ça tire son lot de contrainte. Tu ne peux pas exposer n'importe quoi via des extern "C", et ça peut demander parfois pas mal de contorsions pour arriver à un truc qui marche.
Ensuite, Python et Java étant des langage objets eux aussi, c'est plus facile de mapper le concept d'objet d'un langage vers l'autre en C++ qu'en C.
Alors là, je demande à voir. Tu vas faire du extern "C" de toute façon.
[^] # Re: Oublies le C.
Posté par gaaaaaAab . En réponse au journal C(++) ?. Évalué à 6.
ça dépend. Si tu n'utilises toujours le même compilo sur toutes les plate formes, ça ira. Par contre, si tu utilises le compilo de Sun sur Solaris, le compilo d'HP sur HP-UX, g++ sur Linux, etc ... il vaut mieux ne pas utiliser les fonctionnalités trop récentes, parce qu'elles risquent de n'être supportées que par g++.
je ne parlais pas de l'interprétation des symboles manglés pour qu'ils soient lisibles par un humain (nm -C !!) mais des problèmes d'intégration au runtime.
Le mangling n'étant pas standardisé, chaque compilo utilise le sien propre. Il n'est pas imaginable de linker deux libs binaires produites par deux compilos différents. Si tu compiles tout toi même, pas de problème. Par contre, si tu link sur des libraires externes, en plus de la version de la lib, tu dois gérer un paramètre de dépendance supplémentaire. Eventuellement, si tu récupères une lib binaire dont tu n'as pas les sources, tu te retrouves contraint à l'utilisation du compilateur qui a servi à générer cette lib.
Pire, deux versions différentes d'une même suite de compilation peuvent être incompatibles entre elles (c'est le cas de g++, qui pète régulièrement la compatibilité du mangling).
Côté mise en prod, ça peut aussi être un joyeux boxon. Pour peu que l'infrastructure technique ne soient pas complètement bien contrôlée, et que plusieurs services interviennent ...
oui, tu peux (en fait t'as pas le choix), mais c'est particulièrement pas objet, et ça tire son lot de contrainte. Tu ne peux pas exposer n'importe quoi via des extern "C", et ça peut demander parfois pas mal de contorsions pour arriver à un truc qui marche.
Alors là, je demande à voir. Tu vas faire du extern "C" de toute façon.