Le C++ a beau être standardisé, bien souvent un code prévu pour tel ou
tel compilateur n'est pas compilable avec d'autres, même avec des
bibliothèques identiques.
Quelques exemples :
- Je dois faire des DLL pour AviSynth (logiciel de traitement de
la vidéo). Je n'ai pas réussi à compiler le code sous autre chose que
Visual C++ : Comeau accepte de le compiler mais refuse de faire une
DLL ; gcc et Borland C++ refusent carrément le code.
- J'ai voulu intégrer une bibliothèque open-source, ffmpeg, dans
mon code. J'ai dû y renoncer, car je programme sous BC++ et le code de
la bibliothèque est en gcc. Du coup, j'ai créé une DLL avec g++, que
j'appelle depuis mon programme compilé sous BC++. (Heureusement que
COM m'y autorise !)
- Le mois dernier, je me suis penché sur le remplacement de
Borland C++. J'ai donc essayé de compiler mon code sous Visual C++ et
Comeau. J'ai fini par y arriver (sauf pour le link -- y'a des
ressources qui merdent, mais c'est hors-sujet ici), mais ce fut un
travail assez fastidieux, et j'aurais vraiment eu du mal si ce n'avait
pas été un code que je connais bien.
(J'avais déjà abandonné la piste g++ car je n'avais pas réussi à
y compiler OWL (bibliothèque GUI) correctement.)
Aussi aimerais-je savoir comment vous gérez ce problème, tant pour
votre code (vérification avec plusieurs compilos différents ?), que
pour les bibliothèques (celles dont le source est fourni bien sûr).
Quel est l'intéret de pouvoir compiler un source sur une machine avec différents compilateurs ?
Pour les logiciels "end-user", ça permet de changer de compilateur en cours de développement, si on s'aperçoit qu'il ne convient plus (trop vieux par exemple). Et faire passer un code de g++ 2.9.x à gcc 3.x, ou de Visual C++ 6 à VC++ 7 peut être sacrément problématique, sans même parler de faire passer un code de VC++ 6 à g++ 3.x.
Pour les bibliothèques, le problème est encore plus visible : si une bibliothèque a été prévue pour gcc uniquement, et que je veux l'utiliser dans mon programme développé sous Borland C++ 5.02, je suis dans la merde. Au mieux, je ne passe que quelques jours à rendre le code utilisable ; au pire, je suis obligé d'utiliser des sales bricolages, voire d'abandonner et de chercher une autre bibliothèque.
Idem pour les logiciels "open-source" : bien souvent, il faut avoir la même version du même compilateur que l'auteur du programme pour pouvoir le modifier et le recompiler. On peut même se demander si un logiciel fourni avec ses sources en VC++ 6 peut être appelé "open-source"...
On Thu, 27 Oct 2005 13:46:55 +0200, AG <ag@tb.fr>:
Quel est l'intéret de pouvoir compiler un source sur une machine avec
différents compilateurs ?
Pour les logiciels "end-user", ça permet de changer de compilateur en
cours de développement, si on s'aperçoit qu'il ne convient plus (trop
vieux par exemple). Et faire passer un code de g++ 2.9.x à gcc 3.x, ou
de Visual C++ 6 à VC++ 7 peut être sacrément problématique, sans même
parler de faire passer un code de VC++ 6 à g++ 3.x.
Pour les bibliothèques, le problème est encore plus visible : si une
bibliothèque a été prévue pour gcc uniquement, et que je veux
l'utiliser dans mon programme développé sous Borland C++ 5.02, je suis
dans la merde. Au mieux, je ne passe que quelques jours à rendre le
code utilisable ; au pire, je suis obligé d'utiliser des sales
bricolages, voire d'abandonner et de chercher une autre bibliothèque.
Idem pour les logiciels "open-source" : bien souvent, il faut avoir la
même version du même compilateur que l'auteur du programme pour
pouvoir le modifier et le recompiler.
On peut même se demander si un logiciel fourni avec ses sources en
VC++ 6 peut être appelé "open-source"...
Quel est l'intéret de pouvoir compiler un source sur une machine avec différents compilateurs ?
Pour les logiciels "end-user", ça permet de changer de compilateur en cours de développement, si on s'aperçoit qu'il ne convient plus (trop vieux par exemple). Et faire passer un code de g++ 2.9.x à gcc 3.x, ou de Visual C++ 6 à VC++ 7 peut être sacrément problématique, sans même parler de faire passer un code de VC++ 6 à g++ 3.x.
Pour les bibliothèques, le problème est encore plus visible : si une bibliothèque a été prévue pour gcc uniquement, et que je veux l'utiliser dans mon programme développé sous Borland C++ 5.02, je suis dans la merde. Au mieux, je ne passe que quelques jours à rendre le code utilisable ; au pire, je suis obligé d'utiliser des sales bricolages, voire d'abandonner et de chercher une autre bibliothèque.
Idem pour les logiciels "open-source" : bien souvent, il faut avoir la même version du même compilateur que l'auteur du programme pour pouvoir le modifier et le recompiler. On peut même se demander si un logiciel fourni avec ses sources en VC++ 6 peut être appelé "open-source"...
Dominique.Micollet
In article , "kanze" writes:
et pas de bibliothèque standard, du tout.)
Juste pour ma culture : on fait comment pour se passer des bibliothèques standards ?
-- Cordialement
Dominique MICOLLET Email : enlevez le .fr.fr Universite de Bourgogne 9, Avenue Alain SAVARY BP 47870 Tel : +33/(0)3-80-39-59-27 21078 DIJON CEDEX FRANCE Tfx : +33/(0)3-80-39-68-69
In article <1130401388.911867.251090@g43g2000cwa.googlegroups.com>,
"kanze" <kanze@gabi-soft.fr> writes:
et pas de bibliothèque standard, du tout.)
Juste pour ma culture : on fait comment pour se passer des
bibliothèques standards ?
--
Cordialement
Dominique MICOLLET Email : enlevez le .fr.fr
Universite de Bourgogne
9, Avenue Alain SAVARY BP 47870 Tel : +33/(0)3-80-39-59-27
21078 DIJON CEDEX FRANCE Tfx : +33/(0)3-80-39-68-69
Juste pour ma culture : on fait comment pour se passer des bibliothèques standards ?
-- Cordialement
Dominique MICOLLET Email : enlevez le .fr.fr Universite de Bourgogne 9, Avenue Alain SAVARY BP 47870 Tel : +33/(0)3-80-39-59-27 21078 DIJON CEDEX FRANCE Tfx : +33/(0)3-80-39-68-69
Fabien LE LEZ
On Thu, 27 Oct 2005 14:08:07 +0200, Matthieu Moy :
Ça dépends aussi si tu livres les sources ou le binaire.
Qu'entends-tu par "binaire" ? Si c'est une DLL, suivant le contenu et l'OS, il est possible qu'elle soit compatible avec plusieurs compilateurs. Si c'est une bibliothèque statique, il faut généralement en fournir une par compilateur, et donc il faut que tu puisses compiler ton code sur chaque compilo.
On Thu, 27 Oct 2005 14:08:07 +0200, Matthieu Moy :
Ça dépends aussi si tu livres les sources ou le binaire.
Qu'entends-tu par "binaire" ?
Si c'est une DLL, suivant le contenu et l'OS, il est possible qu'elle
soit compatible avec plusieurs compilateurs.
Si c'est une bibliothèque statique, il faut généralement en fournir
une par compilateur, et donc il faut que tu puisses compiler ton code
sur chaque compilo.
On Thu, 27 Oct 2005 14:08:07 +0200, Matthieu Moy :
Ça dépends aussi si tu livres les sources ou le binaire.
Qu'entends-tu par "binaire" ? Si c'est une DLL, suivant le contenu et l'OS, il est possible qu'elle soit compatible avec plusieurs compilateurs. Si c'est une bibliothèque statique, il faut généralement en fournir une par compilateur, et donc il faut que tu puisses compiler ton code sur chaque compilo.
Fabien LE LEZ
On 27 Oct 2005 14:04:02 +0200, Jean-Marc Bourguet :
Le test est un autre probleme, en particulier quand on maitrise mal les dependances environnementales.
Pas totalement. J'ai vu du code prévu pour gcc compiler sous Borland C++, mais planter à l'exécution, ou vice-versa. Je précise que les tests d'exécution ont été effectués sur la même machine.
Il y a d'ailleurs des chances pour que le code en question ne fonctionne sous gcc que par hasard...
On 27 Oct 2005 14:04:02 +0200, Jean-Marc Bourguet <jm@bourguet.org>:
Le test est un autre probleme, en particulier quand on maitrise mal
les dependances environnementales.
Pas totalement. J'ai vu du code prévu pour gcc compiler sous Borland
C++, mais planter à l'exécution, ou vice-versa. Je précise que les
tests d'exécution ont été effectués sur la même machine.
Il y a d'ailleurs des chances pour que le code en question ne
fonctionne sous gcc que par hasard...
On 27 Oct 2005 14:04:02 +0200, Jean-Marc Bourguet :
Le test est un autre probleme, en particulier quand on maitrise mal les dependances environnementales.
Pas totalement. J'ai vu du code prévu pour gcc compiler sous Borland C++, mais planter à l'exécution, ou vice-versa. Je précise que les tests d'exécution ont été effectués sur la même machine.
Il y a d'ailleurs des chances pour que le code en question ne fonctionne sous gcc que par hasard...
Fabien LE LEZ
On 27 Oct 2005 12:19:27 GMT, :
Juste pour ma culture : on fait comment pour se passer des bibliothèques standards ?
A priori, on ne s'en passe pas. Seuls les appels directs sont interdits ; on n'a le droit de l'utiliser qu'en passant par l'encapsulation officielle.
On 27 Oct 2005 12:19:27 GMT, Dominique.Micollet@u-bourgogne.fr.fr.fr:
Juste pour ma culture : on fait comment pour se passer des
bibliothèques standards ?
A priori, on ne s'en passe pas. Seuls les appels directs sont
interdits ; on n'a le droit de l'utiliser qu'en passant par
l'encapsulation officielle.
Juste pour ma culture : on fait comment pour se passer des bibliothèques standards ?
A priori, on ne s'en passe pas. Seuls les appels directs sont interdits ; on n'a le droit de l'utiliser qu'en passant par l'encapsulation officielle.
Rémy
"Jean-Marc Bourguet" a écrit dans le message de news:
"Rémy" writes:
"Jean-Marc Bourguet" a écrit dans le message de news:
"Rémy" writes:
"Jean-Marc Bourguet" a écrit dans le message de news:
Je crois que le problème est beaucoup plus financier.
Achat des machines, contrats de maintenance, achat des licences des compilateurs,...
Si tu releases sur ces machines avec ces compilateurs, tu les as les machines et les licenses. Donc pour le coût il n'y a "que" le fait de les laisser tourner pendant la nuit les machines faire les builds et les tests.
A+
Tout à fait, mais si tu développes pour une seule cible (ou deux ou trois) en essayant quand même d'être portable (pour le futur par exemple), le coût de cette solution (qui reste malgré tout la seule fiable) est prohibitif.
Quelle solution?
Celle qui permet de s'assurer que le code est compatible avec différents compilateurs: la seule solution est bien d'essayer de builder avec les compilateurs en question.
Je n'ai parle que d'un build regulier sur les plateformes pour lesquelles le programme est release.
J'avais compris "un build régulier sur différentes plateformes", mais je n'ai pas vu "pour lesquelles le programme est releasé"...
Par ailleurs pour un matériel donné, le nombre de combinaisons (version OS + version compilateur + version des outils externes utilisés) est "explosif"...
On est en train de deriver. Au depart la question etait "comment s'assurer qu'on ecrit bien dans le sous-ensemble commun a tous les compilateurs" a laquelle j'ai repondu "nous ne faisons rien de plus que des builds reguliers pour les plateformes pour lesquelles nous releasons".
Le test est un autre probleme, en particulier quand on maitrise mal les dependances environnementales.
Je ne parlais pas des tests, mais bien des builds...
"Jean-Marc Bourguet" <jm@bourguet.org> a écrit dans le message de news:
pxbk6fztbd9.fsf@news.bourguet.org...
"Rémy" <remy.bertrand@wanadoo.fr> writes:
"Jean-Marc Bourguet" <jm@bourguet.org> a écrit dans le message de news:
pxbr7a7uxma.fsf@news.bourguet.org...
"Rémy" <remy.bertrand@wanadoo.fr> writes:
"Jean-Marc Bourguet" <jm@bourguet.org> a écrit dans le message de
news:
pxb3bmnwi7g.fsf@news.bourguet.org...
Je crois que le problème est beaucoup plus financier.
Achat des machines, contrats de maintenance, achat des licences des
compilateurs,...
Si tu releases sur ces machines avec ces compilateurs, tu les as les
machines et les licenses. Donc pour le coût il n'y a "que" le fait de
les laisser tourner pendant la nuit les machines faire les builds et
les tests.
A+
Tout à fait, mais si tu développes pour une seule cible (ou deux ou
trois) en essayant quand même d'être portable (pour le futur par
exemple), le coût de cette solution (qui reste malgré tout la seule
fiable) est prohibitif.
Quelle solution?
Celle qui permet de s'assurer que le code est compatible avec différents
compilateurs: la seule solution est bien d'essayer de builder avec les
compilateurs en question.
Je n'ai parle que d'un build regulier sur les
plateformes pour lesquelles le programme est release.
J'avais compris "un build régulier sur différentes plateformes", mais je
n'ai pas vu "pour lesquelles le programme est releasé"...
Par ailleurs pour un matériel donné, le nombre de combinaisons
(version OS + version compilateur + version des outils externes
utilisés) est "explosif"...
On est en train de deriver. Au depart la question etait "comment
s'assurer qu'on ecrit bien dans le sous-ensemble commun a tous les
compilateurs" a laquelle j'ai repondu "nous ne faisons rien de plus
que des builds reguliers pour les plateformes pour lesquelles nous
releasons".
Le test est un autre probleme, en particulier quand on maitrise mal
les dependances environnementales.
Je ne parlais pas des tests, mais bien des builds...
"Jean-Marc Bourguet" a écrit dans le message de news:
"Rémy" writes:
"Jean-Marc Bourguet" a écrit dans le message de news:
"Rémy" writes:
"Jean-Marc Bourguet" a écrit dans le message de news:
Je crois que le problème est beaucoup plus financier.
Achat des machines, contrats de maintenance, achat des licences des compilateurs,...
Si tu releases sur ces machines avec ces compilateurs, tu les as les machines et les licenses. Donc pour le coût il n'y a "que" le fait de les laisser tourner pendant la nuit les machines faire les builds et les tests.
A+
Tout à fait, mais si tu développes pour une seule cible (ou deux ou trois) en essayant quand même d'être portable (pour le futur par exemple), le coût de cette solution (qui reste malgré tout la seule fiable) est prohibitif.
Quelle solution?
Celle qui permet de s'assurer que le code est compatible avec différents compilateurs: la seule solution est bien d'essayer de builder avec les compilateurs en question.
Je n'ai parle que d'un build regulier sur les plateformes pour lesquelles le programme est release.
J'avais compris "un build régulier sur différentes plateformes", mais je n'ai pas vu "pour lesquelles le programme est releasé"...
Par ailleurs pour un matériel donné, le nombre de combinaisons (version OS + version compilateur + version des outils externes utilisés) est "explosif"...
On est en train de deriver. Au depart la question etait "comment s'assurer qu'on ecrit bien dans le sous-ensemble commun a tous les compilateurs" a laquelle j'ai repondu "nous ne faisons rien de plus que des builds reguliers pour les plateformes pour lesquelles nous releasons".
Le test est un autre probleme, en particulier quand on maitrise mal les dependances environnementales.
Je ne parlais pas des tests, mais bien des builds...
Fabien LE LEZ
On Thu, 27 Oct 2005 13:46:55 +0200, AG :
Quel est l'intéret de pouvoir compiler un source sur une machine avec différents compilateurs ?
Note aussi qu'avec deux compilateurs, tu as deux fois plus de chances d'obtenir un warning en cas de comportement indéfini.
On Thu, 27 Oct 2005 13:46:55 +0200, AG <ag@tb.fr>:
Quel est l'intéret de pouvoir compiler un source sur une machine avec
différents compilateurs ?
Note aussi qu'avec deux compilateurs, tu as deux fois plus de chances
d'obtenir un warning en cas de comportement indéfini.
Quel est l'intéret de pouvoir compiler un source sur une machine avec différents compilateurs ?
Note aussi qu'avec deux compilateurs, tu as deux fois plus de chances d'obtenir un warning en cas de comportement indéfini.
adebaene
Jean-Marc Bourguet wrote:
AG writes:
Quel est l'intéret de pouvoir compiler un source sur une machine avec différents compilateurs ? Le test intéressant n'est-il pas de pouvo ir compiler un code source sur différentes machines ?
Plus tu utilises de compilateurs differents, moins tu as de risque qu'un nouveau compilateur pose un probleme.
Argument spécieux : Si tu cibles *une* plate-forme, quel intérêt d'utiliser plus d'*un* compilateur (et donc quel intérêt d'en tester plusieurs dans l'espoir d'être compatible avec le prochain...) ???
Arnaud
Jean-Marc Bourguet wrote:
AG <ag@tb.fr> writes:
Quel est l'intéret de pouvoir compiler un source sur une machine avec
différents compilateurs ? Le test intéressant n'est-il pas de pouvo ir
compiler un code source sur différentes machines ?
Plus tu utilises de compilateurs differents, moins tu as de risque
qu'un nouveau compilateur pose un probleme.
Argument spécieux : Si tu cibles *une* plate-forme, quel intérêt
d'utiliser plus d'*un* compilateur (et donc quel intérêt d'en tester
plusieurs dans l'espoir d'être compatible avec le prochain...) ???
Quel est l'intéret de pouvoir compiler un source sur une machine avec différents compilateurs ? Le test intéressant n'est-il pas de pouvo ir compiler un code source sur différentes machines ?
Plus tu utilises de compilateurs differents, moins tu as de risque qu'un nouveau compilateur pose un probleme.
Argument spécieux : Si tu cibles *une* plate-forme, quel intérêt d'utiliser plus d'*un* compilateur (et donc quel intérêt d'en tester plusieurs dans l'espoir d'être compatible avec le prochain...) ???
Arnaud
Fabien LE LEZ
On 27 Oct 2005 07:14:53 -0700, :
Si tu cibles *une* plate-forme, quel intérêt d'utiliser plus d'*un* compilateur
Imagine que tu développes sous g++ 2.9.x, et qu'un jour tu décides de passer à g++ 3.x. Ou que tu développes sous Visual C++ 6, et qu'un jour tu décides de passer à Visual C++ 200x.
On 27 Oct 2005 07:14:53 -0700, adebaene@club-internet.fr:
Si tu cibles *une* plate-forme, quel intérêt
d'utiliser plus d'*un* compilateur
Imagine que tu développes sous g++ 2.9.x, et qu'un jour tu décides de
passer à g++ 3.x.
Ou que tu développes sous Visual C++ 6, et qu'un jour tu décides de
passer à Visual C++ 200x.
Si tu cibles *une* plate-forme, quel intérêt d'utiliser plus d'*un* compilateur
Imagine que tu développes sous g++ 2.9.x, et qu'un jour tu décides de passer à g++ 3.x. Ou que tu développes sous Visual C++ 6, et qu'un jour tu décides de passer à Visual C++ 200x.
Matthieu Moy
writes:
Argument spécieux : Si tu cibles *une* plate-forme, quel intérêt d'utiliser plus d'*un* compilateur (et donc quel intérêt d'en tester plusieurs dans l'espoir d'être compatible avec le prochain...) ???
Il y a un truc qui dit que les trucs pas portables sont souvent aussi des trucs « qui craignent » dans l'absolu.
Par exemple, sauf pour des trucs de vraiment bas niveau, tu as rarement envie que ton programme soit sensible à l'endianness, même si tu n'as qu'une seule cible (si tu es sensible à l'endianness sans t'en rendre compte, il y a 95% de chances pour que tu te soit gourré dans un cast).
L'autre intérêt, c'est que même si a un instant t, tu ne vises qu'une seule plateforme, c'est quand même une bonne idée de ne pas se bloquer la possibilité d'une migration future. Par exemple, le noyau Linux est testé avec des versions de développement de GCC, alors que personne n'utilise pour de vrai ces versions de développement, mais ça permet d'anticiper les problèmes (là, j'admet que c'est un cas particulier, puisque les gens savent qu'ils vont migrer vers la version suivante de GCC).
-- Matthieu
adebaene@club-internet.fr writes:
Argument spécieux : Si tu cibles *une* plate-forme, quel intérêt
d'utiliser plus d'*un* compilateur (et donc quel intérêt d'en tester
plusieurs dans l'espoir d'être compatible avec le prochain...) ???
Il y a un truc qui dit que les trucs pas portables sont souvent aussi
des trucs « qui craignent » dans l'absolu.
Par exemple, sauf pour des trucs de vraiment bas niveau, tu as
rarement envie que ton programme soit sensible à l'endianness, même si
tu n'as qu'une seule cible (si tu es sensible à l'endianness sans t'en
rendre compte, il y a 95% de chances pour que tu te soit gourré dans
un cast).
L'autre intérêt, c'est que même si a un instant t, tu ne vises qu'une
seule plateforme, c'est quand même une bonne idée de ne pas se bloquer
la possibilité d'une migration future. Par exemple, le noyau Linux est
testé avec des versions de développement de GCC, alors que personne
n'utilise pour de vrai ces versions de développement, mais ça permet
d'anticiper les problèmes (là, j'admet que c'est un cas particulier,
puisque les gens savent qu'ils vont migrer vers la version suivante de
GCC).
Argument spécieux : Si tu cibles *une* plate-forme, quel intérêt d'utiliser plus d'*un* compilateur (et donc quel intérêt d'en tester plusieurs dans l'espoir d'être compatible avec le prochain...) ???
Il y a un truc qui dit que les trucs pas portables sont souvent aussi des trucs « qui craignent » dans l'absolu.
Par exemple, sauf pour des trucs de vraiment bas niveau, tu as rarement envie que ton programme soit sensible à l'endianness, même si tu n'as qu'une seule cible (si tu es sensible à l'endianness sans t'en rendre compte, il y a 95% de chances pour que tu te soit gourré dans un cast).
L'autre intérêt, c'est que même si a un instant t, tu ne vises qu'une seule plateforme, c'est quand même une bonne idée de ne pas se bloquer la possibilité d'une migration future. Par exemple, le noyau Linux est testé avec des versions de développement de GCC, alors que personne n'utilise pour de vrai ces versions de développement, mais ça permet d'anticiper les problèmes (là, j'admet que c'est un cas particulier, puisque les gens savent qu'ils vont migrer vers la version suivante de GCC).
