gratifiant > comp.lang.* > comp.lang.cpp

Fabien LE LEZ (26/10/2005, 16h33)
Bâjour,

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).

Merci d'avance...
Aurélien Barbier-Accary (26/10/2005, 16h54)
Fabien LE LEZ a écrit :
[..]
> votre code (vérification avec plusieurs compilos différents ?), que
> pour les bibliothèques (celles dont le source est fourni bien sûr).
> Merci d'avance...


moi naivement je compile (sous g++) avec -ansi -pedantic et je me dis que ça
doit quasiment suffir à assurer la compatibilité du code source...
Mais ça ne résoud pas le problème de l'utilisation de librairies extérieures.
Désolé de ne pas pouvoir t'aider vraiment.
Jean-Marc Bourguet (26/10/2005, 16h55)
Fabien LE LEZ <gramster> writes:

> 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).


Nous avons simplement des builds reguliers (pas toutes les nuits mais
quand meme plusieurs fois par semaine) par plateforme (Solaris 32,
Solaris 64, HP-UX 32, HP-UX 64, AIX 32, AIX 64, Linux x86, Linux ia64,
Linux amd64 et on va peut-etre ajouter Solaris x86, Solarix amd64) Les
developpeurs ne verifient que sur la platerforme sur laquelle ils
developpent (Solaris 32, Linux x86) et les CM (ceux qui s'occupent du
Configuration Management) notifient le dernier a avoir fait un check
in d'un fichier des pb de compilation eventuel sur les autres
plateformes.

A+
Casillux (26/10/2005, 20h23)
Jean-Marc Bourguet wrote:
> Fabien LE LEZ <gramster> writes:
>>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).

> Nous avons simplement des builds reguliers


J'aime bien le "simplement" tout à fait à la porté d'un particulier :-).
Fabien LE LEZ (26/10/2005, 20h38)
On 26 Oct 2005 16:55:50 +0200, Jean-Marc Bourguet <jm>:

>Nous avons simplement des builds reguliers [...] par plateforme


Avec des compilateurs différents, ou uniquement gcc ?
Marc Boyer (26/10/2005, 21h19)
Casillux <gellysv> a écrit :
> Jean-Marc Bourguet wrote:
> J'aime bien le "simplement" tout à fait à la porté d'un particulier :-).


Même pour certaines PME, maintenir la douzaine de machine
cible n'est pas évident.

Marc Boyer
Fabien LE LEZ (26/10/2005, 21h26)
On Wed, 26 Oct 2005 20:23:51 +0200, Casillux
<gellysv>:

>> Nous avons simplement des builds reguliers

>J'aime bien le "simplement" tout à fait à la porté d'un particulier :-).


Remarque que si effectivement avoir une quinzaine de machines
différentes n'est pas à la portée du premier venu, tester le code avec
plusieurs compilateurs sur une machine donnée est nettement plus
abordable... mais encore faut-il la volonté de faire du code
compatible.
Jean-Marc Bourguet (27/10/2005, 08h45)
Fabien LE LEZ <gramster> writes:

> On 26 Oct 2005 16:55:50 +0200, Jean-Marc Bourguet <jm>:
> >Nous avons simplement des builds reguliers [...] par plateforme

> Avec des compilateurs différents, ou uniquement gcc ?


Avec les compilateurs qu'on utilise sur la plateforme (SparcWorks sur
Sun, aCC sur HP-UX, xlC sur IBM, g++ sur Linux) bien qu'il y a eu au
moins un projet qui utilisait g++ aussi sur Sun pour le developpement
(mais pas pour la release).

A+
Jean-Marc Bourguet (27/10/2005, 09h00)
Casillux <gellysv> writes:

> Jean-Marc Bourguet wrote:
> J'aime bien le "simplement" tout à fait à la porté d'un particulier:-).


Je pourrais imaginer facilement des choses plus compliquees (compiler
sur des plateformes pour lesquelles on ne fait pas de release,
compiler avec d'autres compilateurs que ceux qui servent pour les
releases, compiler automatiquement avant le checkin dans le systeme de
gestion de source sur toutes les plateformes et refuser si ca ne
compile pas, utiliser des verificateurs statiques de code, ...)

Avoir des builds reguliers pour toutes les machines dont on dispose ne
necessite pas grand chose tant qu'on a un support adequat de l'OS. Le
support batch/cron de Unix est minimal -- moins que ca on ne peut pas
dire que c'est fourni par l'OS -- et pourtant il suffit.

De toute facon, batir comme ca n'est que la premiere etape, apres il
faut executer les tests.

A+
Jean-Marc Bourguet (27/10/2005, 09h08)
Marc Boyer <Marc.Boyer> writes:

> Casillux <gellysv> a écrit :
> Même pour certaines PME, maintenir la douzaine de machine cible
> n'est pas évident.


Pour une PME qui fait du software, ca ne devrait pas poser de
probleme. Le mieux est d'avoir quelqu'un qui l'a deja fait, ca evite
de tatonner un temps -- mais sinon administrer un parc de machines
unix meme heterogene et y mettre en place un environnement de
developpement a moitie raisonnable, c'est pas complique (je l'ai fait
quand j'etais a la fac en me formant moi-meme la dessus et en ayant
d'autres charges en meme temps).

Je fonderais une societe unipersonnelle pour faire du soft, le premier
code -- a moins que je trouve quelque chose de tout fait -- que
j'ecrirais serait pour mettre ca en place.

A+
Rémy (27/10/2005, 10h19)
"Jean-Marc Bourguet" <jm> a écrit dans le message de news:
pxb3bmnwi7g.fsf...
> Marc Boyer <Marc.Boyer> writes:
> Pour une PME qui fait du software, ca ne devrait pas poser de
> probleme. Le mieux est d'avoir quelqu'un qui l'a deja fait, ca evite
> de tatonner un temps -- mais sinon administrer un parc de machines
> unix meme heterogene et y mettre en place un environnement de
> developpement a moitie raisonnable, c'est pas complique (je l'ai fait
> quand j'etais a la fac en me formant moi-meme la dessus et en ayant
> d'autres charges en meme temps).


Je crois que le problème est beaucoup plus financier.

Achat des machines, contrats de maintenance, achat des licences des
compilateurs,...

Rémy
Marc Boyer (27/10/2005, 10h22)
Le 27-10-2005, Jean-Marc Bourguet <jm> a écrit :
> Marc Boyer <Marc.Boyer> writes:
> Pour une PME qui fait du software, ca ne devrait pas poser de
> probleme.


Je suis client d'une (petite) société qui n'y arrive pas.
Quand on leur a signalé un pb de compatibilité Tcl/Tk avec
Solaris 9, ils nous on dit avoir en projet de bientôt y passer.
Et notre admin qui pensait être en retard pour le passage
à Solaris 10.
Cette société offre par ailleurs un bon produit, un bon
SAV. Donc, j'en ai déduit que ça n'était pas si facile pour
eux (mais ce sont des suppositions externes).

Marc Boyer
kanze (27/10/2005, 10h23)
Casillux wrote:
> Jean-Marc Bourguet wrote:
> > Fabien LE LEZ <gramster> writes:


> >>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).


> > Nous avons simplement des builds reguliers


> J'aime bien le "simplement" tout à fait à la porté d'un
> particulier :-).


Il n'y a pas d'autre solution. Le seul code portable, c'est du
code qui a été porté.

En C++, il y a deux sources de problèmes en ce qui concerne la
portabilité :

-- Le langage a pas mal évolué, il y a un certain temps. Et
même aujourd'hui, il y a très peu de compilateurs conforme.
Il existe bien un sous-ensemble du langage qu'on peut
utiliser sans trop de problèmes, un sous-ensemble qui ne
cesse de croître, d'ailleurs. Mais il faut bien que l'auteur
du code ait eu l'intention de le rendre portable, a bien
défini ce sous-ensemble, et en a respecté les limites quand
il écrivait le code. (La seule façon d'être sûr du dernier,
c'est de l'avoir compilé avec tous les compilateurs
concernés.)

-- Le langage, même avec ses bibliothèques, est loin de définir
tout ce dont on a besoin -- il n'y a pas de sockets, pas de
threads, pas de GUI... Du coup, il est plutôt rare qu'un
programme n'utilise rien sauf ce qui est défini par le
langage. Et évidemment, si j'écris mon code en me servant de
pthread_create, par exemple, la portabilité vers Windows est
fortement compromise.

Parmi d'autres choses, Fabien a parlé des DLL. C'est une chose
qui n'est pas définie par le langage, et dont la gestion, et
même la philosophie, diffèrent énormement entre Unix et Windows.
Du coup, le probabilité qu'un logiciel développé sous Unix fait
quelque chose d'utilisable à cet égard sous Windows est assez
faible.

Ayant dit tout ça, il y a des programmes écrits en C++ qui
marchent sur beaucoup de plateformes différents : tout ce qui
sort de Mozilla (firefox, thunderbird, etc.), par exemple. Mais
si tu régardes leurs règles
(), les
constraints sont assez draconiens. (La version actuelle permet
des templates, quand même. Ce n'était pas le cas il y a deux ou
trois ans. Mais pas d'exceptions, pas de RTTI, pas de namespace
et pas de bibliothèque standard, du tout.)
Fabien LE LEZ (27/10/2005, 10h35)
On 27 Oct 2005 01:23:08 -0700, "kanze" <kanze>:

>Et évidemment, si j'écris mon code en me servant de
> pthread_create, par exemple, la portabilité vers Windows est
> fortement compromise.


Je crois avoir lu (dans "Programming with POSIX threads") que les
pthreads ont été portés sous Windows.

Porter un programme Unix sous Windows (ou vice-versa) n'est pas de la
tarte, mais c'est tout de même de plus en plus facile.

Est-ce qu'il existe d'autres OS, au fait, en-dehors de l'embarqué (et
des musées) ?

>tout ce qui
>sort de Mozilla (firefox, thunderbird, etc.), par exemple. Mais
>si tu régardes leurs règles
>(), les
>constraints sont assez draconiens.


Il y a une différence de taille entre la volonté d'être compatible
avec tous les compilos, et celle d'être compatible avec tous les
compilateurs récents.

En prime, si le logiciel n'est pas compatible MacOS9 (par exemple), il
n'est pas très utile que le code soit accepté par un compilo prévu
pour MacOS9...
kanze (27/10/2005, 10h38)
Aurélien Barbier-Accary wrote:
> Fabien LE LEZ a écrit :


> moi naivement je compile (sous g++) avec -ansi -pedantic et je
> me dis que ça doit quasiment suffir à assurer la compatibilité
> du code source...


Tu rigoles, n'est-ce pas ? Tu as oublié le :-). Le code qui
passe une version de g++ avec ses options ne passe même pas
forcement la prochaine version -- j'ai dû réécrire beaucoup de
choses lors du passage de 2.95.2 à 3.4.3, par exemple, et il y a
toujours des rapports des choses qui marchait en 3.3.x, mais non
en 3.4.x. Et je ne parle que de g++ -- si j'ajoute Sun CC (qui
est encore très loin de la norme), la situation s'empire.

Le problème actuellement, c'est qu'il y a très peu de
compilateurs réelement conformes -- g++ (au moins 3.4.3) ne
l'est pas totalement, et certains autres (comme Sun CC) en sont
encore plus loin. Du coup, même si tu écris du code 100%
conforme, il n'y a aucune garantie à ce qu'un compilateur donné
ne l'accepte.

> Mais ça ne résoud pas le problème de l'utilisation de
> librairies extérieures.


Ni des ressources système non-standardisées. Fabien a parlé des
problèmes de chargement dynamique -- j'utilise dlopen() et
dlsym() pour le faire, mais je parie que ça ne marcherait pas
chez lui. Pire... dans ce cas-ci, Microsoft a défini des
extensions du langage pour le mieux supporter. Extensions dont
on se servent d'habitude dans toutes les sources qui vont faire
partie d'une DLL. (Je crois qu'il y a des possibilités de mettre
l'information nécessaire dans un fichier à part, plutôt que
d'utiliser les extensions dans la source. Mais je n'ai jamais
parlé avec quelqu'un qui s'en est servi.)

Discussions similaires