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).
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 :-).
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.
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 -- À vélo, prendre une rue à contre-sens est moins dangereux que prendre un boulevard dans le sens légal. À qui la faute ?
Le 27-10-2005, Jean-Marc Bourguet <jm@bourguet.org> a écrit :
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Casillux <gellysv@pasdespammerci.yahoo.fr> a écrit :
Jean-Marc Bourguet wrote:
Fabien LE LEZ <gramster@gramster.com> 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 :-).
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.
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
--
À vélo, prendre une rue à contre-sens est moins dangereux
que prendre un boulevard dans le sens légal. À qui la faute ?
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 :-).
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.
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 -- À vélo, prendre une rue à contre-sens est moins dangereux que prendre un boulevard dans le sens légal. À qui la faute ?
kanze
Casillux wrote:
Jean-Marc Bourguet wrote:
Fabien LE LEZ 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 (http://www.mozilla.org/hacking/portable-cpp.html), 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.)
-- James Kanze GABI Software 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
Casillux wrote:
Jean-Marc Bourguet wrote:
Fabien LE LEZ <gramster@gramster.com> 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
(http://www.mozilla.org/hacking/portable-cpp.html), 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.)
--
James Kanze GABI Software
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
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 (http://www.mozilla.org/hacking/portable-cpp.html), 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.)
-- James Kanze GABI Software 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
Fabien LE LEZ
On 27 Oct 2005 01:23:08 -0700, "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 (http://www.mozilla.org/hacking/portable-cpp.html), 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...
On 27 Oct 2005 01:23:08 -0700, "kanze" <kanze@gabi-soft.fr>:
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
(http://www.mozilla.org/hacking/portable-cpp.html), 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...
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 (http://www.mozilla.org/hacking/portable-cpp.html), 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
Aurélien Barbier-Accary wrote:
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.)
-- James Kanze GABI Software 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
Aurélien Barbier-Accary wrote:
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.)
--
James Kanze GABI Software
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
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.)
-- James Kanze GABI Software 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
Jean-Marc Bourguet
"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+
-- 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
"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+
--
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
"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+
-- 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
Fabien LE LEZ
On 27 Oct 2005 01:38:00 -0700, "kanze" :
Ni des ressources système non-standardisées. Fabien a parlé des problèmes de chargement dynamique
Je ne crois pas que ce soit un si gros problème que ça : soit on fait du code spécifique Windows, et ça marche bien, soit on fait du code qu'on espère portable vers Unix, et on se démerde pour éviter les DLL.
Ce qui m'intéressait ici, c'est plus la portabilité inter-compilateurs, même sur un OS unique : est-ce que du code Visual C++ a une chance d'être compilé sous gcc, en supposant qu'on a les mêmes bibliothèques pour les deux compilos ?
J'ai l'impression que la majorité des programmeurs ne sont même pas au courant du problème -- voire, ne sont pas au courant qu'il existe un autre compilo que celui qu'ils utilisent. En gros, si Visual C++ autorise "main()" à la place de "int main()", je l'utilise sans vergogne, et tant pis si d'autres compilateurs râlent ("Uh ? Il existerait d'autres compilateurs ? Tu plaisantes ?")
On 27 Oct 2005 01:38:00 -0700, "kanze" <kanze@gabi-soft.fr>:
Ni des ressources système non-standardisées. Fabien a parlé des
problèmes de chargement dynamique
Je ne crois pas que ce soit un si gros problème que ça : soit on fait
du code spécifique Windows, et ça marche bien, soit on fait du code
qu'on espère portable vers Unix, et on se démerde pour éviter les DLL.
Ce qui m'intéressait ici, c'est plus la portabilité
inter-compilateurs, même sur un OS unique : est-ce que du code Visual
C++ a une chance d'être compilé sous gcc, en supposant qu'on a les
mêmes bibliothèques pour les deux compilos ?
J'ai l'impression que la majorité des programmeurs ne sont même pas au
courant du problème -- voire, ne sont pas au courant qu'il existe un
autre compilo que celui qu'ils utilisent. En gros, si Visual C++
autorise "main()" à la place de "int main()", je l'utilise sans
vergogne, et tant pis si d'autres compilateurs râlent ("Uh ? Il
existerait d'autres compilateurs ? Tu plaisantes ?")
Ni des ressources système non-standardisées. Fabien a parlé des problèmes de chargement dynamique
Je ne crois pas que ce soit un si gros problème que ça : soit on fait du code spécifique Windows, et ça marche bien, soit on fait du code qu'on espère portable vers Unix, et on se démerde pour éviter les DLL.
Ce qui m'intéressait ici, c'est plus la portabilité inter-compilateurs, même sur un OS unique : est-ce que du code Visual C++ a une chance d'être compilé sous gcc, en supposant qu'on a les mêmes bibliothèques pour les deux compilos ?
J'ai l'impression que la majorité des programmeurs ne sont même pas au courant du problème -- voire, ne sont pas au courant qu'il existe un autre compilo que celui qu'ils utilisent. En gros, si Visual C++ autorise "main()" à la place de "int main()", je l'utilise sans vergogne, et tant pis si d'autres compilateurs râlent ("Uh ? Il existerait d'autres compilateurs ? Tu plaisantes ?")
Fabien LE LEZ
On 27 Oct 2005 11:18:05 +0200, Jean-Marc Bourguet :
Si tu releases sur ces machines avec ces compilateurs, tu les as les machines et les licenses.
Sous Windows le problème est assez différent : l'exécutable est le même pour toutes les versions, mais en théorie on devrait tester chaque release sur les dizaines de versions différentes (NT4, NT4 SP3, NT4 SP4, NT4 SP5, NT4 SP6, W2K, W2K SP1, W2K SP2, W2K SP1 avec IE6, W2K SP1 avec IE 5.5, etc.)
On 27 Oct 2005 11:18:05 +0200, Jean-Marc Bourguet <jm@bourguet.org>:
Si tu releases sur ces machines avec ces compilateurs, tu les as les
machines et les licenses.
Sous Windows le problème est assez différent : l'exécutable est le
même pour toutes les versions, mais en théorie on devrait tester
chaque release sur les dizaines de versions différentes (NT4, NT4 SP3,
NT4 SP4, NT4 SP5, NT4 SP6, W2K, W2K SP1, W2K SP2, W2K SP1 avec IE6,
W2K SP1 avec IE 5.5, etc.)
On 27 Oct 2005 11:18:05 +0200, Jean-Marc Bourguet :
Si tu releases sur ces machines avec ces compilateurs, tu les as les machines et les licenses.
Sous Windows le problème est assez différent : l'exécutable est le même pour toutes les versions, mais en théorie on devrait tester chaque release sur les dizaines de versions différentes (NT4, NT4 SP3, NT4 SP4, NT4 SP5, NT4 SP6, W2K, W2K SP1, W2K SP2, W2K SP1 avec IE6, W2K SP1 avec IE 5.5, etc.)
Jean-Marc Bourguet
Marc Boyer writes:
Le 27-10-2005, Jean-Marc Bourguet a écrit :
Marc Boyer writes:
Casillux a écrit :
Jean-Marc Bourguet wrote:
Fabien LE LEZ 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 :-).
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.
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.
Le probleme est different. Changer de version supportee d'OS ou de compilateur est un processus assez lourd et long de validation. Ou bien ca ralenti le developppement et le support, ou bien il y a des gens qui s'en occupent en plus.
Et notre admin qui pensait être en retard pour le passage à Solaris 10.
$ uname -a SunOS cdssoph29 5.8 Generic_117350-04 sun4u sparc SUNW,Sun-Blade-1500
Mais il me semble qu'on teste aussi avec autre chose. (Sur Sun c'est difficile de batir avec une version d'OS quelque chose qui tourne sur la version precedente; donc le developpement est toujours sur la plus ancienne version supportee. Et certains de nos clients fonctionnent en choississant une version de base au debut d'un projet et n'en change pas jusqu'a la fin du projet).
A+
-- 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
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Le 27-10-2005, Jean-Marc Bourguet <jm@bourguet.org> a écrit :
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Casillux <gellysv@pasdespammerci.yahoo.fr> a écrit :
Jean-Marc Bourguet wrote:
Fabien LE LEZ <gramster@gramster.com> 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 :-).
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.
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.
Le probleme est different. Changer de version supportee d'OS ou de
compilateur est un processus assez lourd et long de validation. Ou
bien ca ralenti le developppement et le support, ou bien il y a des
gens qui s'en occupent en plus.
Et notre admin qui pensait être en retard pour le passage
à Solaris 10.
$ uname -a
SunOS cdssoph29 5.8 Generic_117350-04 sun4u sparc SUNW,Sun-Blade-1500
Mais il me semble qu'on teste aussi avec autre chose. (Sur Sun c'est
difficile de batir avec une version d'OS quelque chose qui tourne sur
la version precedente; donc le developpement est toujours sur la plus
ancienne version supportee. Et certains de nos clients fonctionnent
en choississant une version de base au debut d'un projet et n'en
change pas jusqu'a la fin du projet).
A+
--
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
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 :-).
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.
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.
Le probleme est different. Changer de version supportee d'OS ou de compilateur est un processus assez lourd et long de validation. Ou bien ca ralenti le developppement et le support, ou bien il y a des gens qui s'en occupent en plus.
Et notre admin qui pensait être en retard pour le passage à Solaris 10.
$ uname -a SunOS cdssoph29 5.8 Generic_117350-04 sun4u sparc SUNW,Sun-Blade-1500
Mais il me semble qu'on teste aussi avec autre chose. (Sur Sun c'est difficile de batir avec une version d'OS quelque chose qui tourne sur la version precedente; donc le developpement est toujours sur la plus ancienne version supportee. Et certains de nos clients fonctionnent en choississant une version de base au debut d'un projet et n'en change pas jusqu'a la fin du projet).
A+
-- 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
Jean-Marc Bourguet
Fabien LE LEZ writes:
On 27 Oct 2005 11:18:05 +0200, Jean-Marc Bourguet :
Si tu releases sur ces machines avec ces compilateurs, tu les as les machines et les licenses.
Sous Windows le problème est assez différent : l'exécutable est le même pour toutes les versions, mais en théorie on devrait tester chaque release sur les dizaines de versions différentes (NT4, NT4 SP3, NT4 SP4, NT4 SP5, NT4 SP6, W2K, W2K SP1, W2K SP2, W2K SP1 avec IE6, W2K SP1 avec IE 5.5, etc.)
Nous sommes en position d'imposer un ensemble minimum de patch installe et de patchs absent. On fournit meme a nos clients un programme pour verifier que leur systeme a tout ce qu'il faut et rien de ce qu'il ne faut pas :-)
A+
-- 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
Fabien LE LEZ <gramster@gramster.com> writes:
On 27 Oct 2005 11:18:05 +0200, Jean-Marc Bourguet <jm@bourguet.org>:
Si tu releases sur ces machines avec ces compilateurs, tu les as les
machines et les licenses.
Sous Windows le problème est assez différent : l'exécutable est le
même pour toutes les versions, mais en théorie on devrait tester
chaque release sur les dizaines de versions différentes (NT4, NT4 SP3,
NT4 SP4, NT4 SP5, NT4 SP6, W2K, W2K SP1, W2K SP2, W2K SP1 avec IE6,
W2K SP1 avec IE 5.5, etc.)
Nous sommes en position d'imposer un ensemble minimum de patch
installe et de patchs absent. On fournit meme a nos clients un
programme pour verifier que leur systeme a tout ce qu'il faut et rien
de ce qu'il ne faut pas :-)
A+
--
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
On 27 Oct 2005 11:18:05 +0200, Jean-Marc Bourguet :
Si tu releases sur ces machines avec ces compilateurs, tu les as les machines et les licenses.
Sous Windows le problème est assez différent : l'exécutable est le même pour toutes les versions, mais en théorie on devrait tester chaque release sur les dizaines de versions différentes (NT4, NT4 SP3, NT4 SP4, NT4 SP5, NT4 SP6, W2K, W2K SP1, W2K SP2, W2K SP1 avec IE6, W2K SP1 avec IE 5.5, etc.)
Nous sommes en position d'imposer un ensemble minimum de patch installe et de patchs absent. On fournit meme a nos clients un programme pour verifier que leur systeme a tout ce qu'il faut et rien de ce qu'il ne faut pas :-)
A+
-- 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
Jean-Marc Bourguet
Fabien LE LEZ writes:
Est-ce qu'il existe d'autres OS, au fait, en-dehors de l'embarqué (et des musées) ?
OpenVMS n'etaient pas encore tout a fait mort la derniere fois que j'ai entendu parle de lui, IBM a quelques OS pour les descendants des 360 et des AS/400 (je ne me retrouve pas dans leurs nouveaux noms en ?Series), Unisys vendait toujours la derniere fois que j'ai regarde des machines 36 bits en complement a un descendant des 2200, je doute que Windows ou Unix tournent la dessus.
A+
-- 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
Fabien LE LEZ <gramster@gramster.com> writes:
Est-ce qu'il existe d'autres OS, au fait, en-dehors de l'embarqué (et
des musées) ?
OpenVMS n'etaient pas encore tout a fait mort la derniere fois que
j'ai entendu parle de lui, IBM a quelques OS pour les descendants des
360 et des AS/400 (je ne me retrouve pas dans leurs nouveaux noms en
?Series), Unisys vendait toujours la derniere fois que j'ai regarde
des machines 36 bits en complement a un descendant des 2200, je doute
que Windows ou Unix tournent la dessus.
A+
--
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
Est-ce qu'il existe d'autres OS, au fait, en-dehors de l'embarqué (et des musées) ?
OpenVMS n'etaient pas encore tout a fait mort la derniere fois que j'ai entendu parle de lui, IBM a quelques OS pour les descendants des 360 et des AS/400 (je ne me retrouve pas dans leurs nouveaux noms en ?Series), Unisys vendait toujours la derniere fois que j'ai regarde des machines 36 bits en complement a un descendant des 2200, je doute que Windows ou Unix tournent la dessus.
A+
-- 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
