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).
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.
Bien.
Mais alors comment cela peut il régler le problème de bibliothèques standard incompatibles avec les divers compilateurs : est ce que sont fournies des encapsulations qui prévoient tous les cas ?
Et si j'ai besoin d'une bibliothèque standard qui n'a pas été encapsulée, j'imagine qu'avant de l'utiliser, je dois l'encapsuler et la faire valider ?
-- 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 <lth1m156chej97hij0cp4vfhekbh228oj3@4ax.com>,
Fabien LE LEZ <gramster@gramster.com> writes:
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.
Bien.
Mais alors comment cela peut il régler le problème de bibliothèques
standard incompatibles avec les divers compilateurs : est ce que sont
fournies des encapsulations qui prévoient tous les cas ?
Et si j'ai besoin d'une bibliothèque standard qui n'a pas été
encapsulée, j'imagine qu'avant de l'utiliser, je dois l'encapsuler et
la faire valider ?
--
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
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.
Bien.
Mais alors comment cela peut il régler le problème de bibliothèques standard incompatibles avec les divers compilateurs : est ce que sont fournies des encapsulations qui prévoient tous les cas ?
Et si j'ai besoin d'une bibliothèque standard qui n'a pas été encapsulée, j'imagine qu'avant de l'utiliser, je dois l'encapsuler et la faire valider ?
-- 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 27 Oct 2005 16:01:05 GMT, :
Bien.
Cette affirmation n'engage que toi.
On 27 Oct 2005 16:01:05 GMT, Dominique.Micollet@u-bourgogne.fr.fr.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.
Ça dépend ce que tu fais. Ici, il y a pas mal du code qui tourne à la fois sous Solaris et sous Windows, et qui fait partie d'un objet chargé dynamiquement -- un DLL sous Windows, et un .so sous Solaris.
En ce qui concerne les ressources, on les a encapsulé, pour la plupart, de façon qu'il y a réelement deux implémentations, mais que le code des utilisateurs ne change pas.
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 ?
Je ne sais pas. Il ne me serait jamais venu à l'ésprit d'utiliser g++ sous Windows. En ce qui concerne les DLL's, j'ai quand même mes doutes. Est-ce que les versions Windows de g++ aient des extensions Microsoft qui servent dans ces cas-là ?
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.
Ça m'étonnera un peu. Je ne sais pas ce que font la majorité des programmeurs, mais dans la pratique, il y a encore énormement de choses qu'un PC ne sait pas faire, et pour lesquelles il faut un système plus poussé. Et quand il s'agit des logiciels sur mesure, qui à mon avis doivent occuper la plupart des programmeurs, ces machines-là servent assez souvent. Il y a bien dix fois plus de PC que de machines Unix, mais d'après ce que je vois, quand on écrit un programme pour un PC, il tourne sur des centaines de PC, sinon des milliers. Tandis qu'il y a beaucoup de programmes qu'on écrit pour une machine Unix qui ne tourne que sur une ou deux machines.
Aussi, les programmes pour les machines Unix sont souvent plus grands, et occupent plus de programmeurs.
De l'autre côté, j'ai l'impression que les programmes sur les machines Unix servent plus longtemps. On l'écrit, puis il tourne quelques années, avec seulement de petites modifications. Tandis que sur les PC, on livre, et trois mois plus tard, il faut un nouveau programme.
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 ?")
Je crois que c'est un phénomène surtout chez certains débuttants. Dans la pratique, je vois mal un programmeur qui ne vit que d'un seul système (encore que je m'en tire pas trop mal sans toucher à Windows).
-- 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 wrote:
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.
Ça dépend ce que tu fais. Ici, il y a pas mal du code qui tourne
à la fois sous Solaris et sous Windows, et qui fait partie d'un
objet chargé dynamiquement -- un DLL sous Windows, et un .so
sous Solaris.
En ce qui concerne les ressources, on les a encapsulé, pour la
plupart, de façon qu'il y a réelement deux implémentations, mais
que le code des utilisateurs ne change pas.
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 ?
Je ne sais pas. Il ne me serait jamais venu à l'ésprit
d'utiliser g++ sous Windows. En ce qui concerne les DLL's, j'ai
quand même mes doutes. Est-ce que les versions Windows de g++
aient des extensions Microsoft qui servent dans ces cas-là ?
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.
Ça m'étonnera un peu. Je ne sais pas ce que font la majorité des
programmeurs, mais dans la pratique, il y a encore énormement de
choses qu'un PC ne sait pas faire, et pour lesquelles il faut un
système plus poussé. Et quand il s'agit des logiciels sur
mesure, qui à mon avis doivent occuper la plupart des
programmeurs, ces machines-là servent assez souvent. Il y a bien
dix fois plus de PC que de machines Unix, mais d'après ce que je
vois, quand on écrit un programme pour un PC, il tourne sur des
centaines de PC, sinon des milliers. Tandis qu'il y a beaucoup
de programmes qu'on écrit pour une machine Unix qui ne tourne
que sur une ou deux machines.
Aussi, les programmes pour les machines Unix sont souvent plus
grands, et occupent plus de programmeurs.
De l'autre côté, j'ai l'impression que les programmes sur les
machines Unix servent plus longtemps. On l'écrit, puis il tourne
quelques années, avec seulement de petites modifications. Tandis
que sur les PC, on livre, et trois mois plus tard, il faut un
nouveau programme.
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 ?")
Je crois que c'est un phénomène surtout chez certains
débuttants. Dans la pratique, je vois mal un programmeur qui ne
vit que d'un seul système (encore que je m'en tire pas trop mal
sans toucher à Windows).
--
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
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.
Ça dépend ce que tu fais. Ici, il y a pas mal du code qui tourne à la fois sous Solaris et sous Windows, et qui fait partie d'un objet chargé dynamiquement -- un DLL sous Windows, et un .so sous Solaris.
En ce qui concerne les ressources, on les a encapsulé, pour la plupart, de façon qu'il y a réelement deux implémentations, mais que le code des utilisateurs ne change pas.
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 ?
Je ne sais pas. Il ne me serait jamais venu à l'ésprit d'utiliser g++ sous Windows. En ce qui concerne les DLL's, j'ai quand même mes doutes. Est-ce que les versions Windows de g++ aient des extensions Microsoft qui servent dans ces cas-là ?
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.
Ça m'étonnera un peu. Je ne sais pas ce que font la majorité des programmeurs, mais dans la pratique, il y a encore énormement de choses qu'un PC ne sait pas faire, et pour lesquelles il faut un système plus poussé. Et quand il s'agit des logiciels sur mesure, qui à mon avis doivent occuper la plupart des programmeurs, ces machines-là servent assez souvent. Il y a bien dix fois plus de PC que de machines Unix, mais d'après ce que je vois, quand on écrit un programme pour un PC, il tourne sur des centaines de PC, sinon des milliers. Tandis qu'il y a beaucoup de programmes qu'on écrit pour une machine Unix qui ne tourne que sur une ou deux machines.
Aussi, les programmes pour les machines Unix sont souvent plus grands, et occupent plus de programmeurs.
De l'autre côté, j'ai l'impression que les programmes sur les machines Unix servent plus longtemps. On l'écrit, puis il tourne quelques années, avec seulement de petites modifications. Tandis que sur les PC, on livre, et trois mois plus tard, il faut un nouveau programme.
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 ?")
Je crois que c'est un phénomène surtout chez certains débuttants. Dans la pratique, je vois mal un programmeur qui ne vit que d'un seul système (encore que je m'en tire pas trop mal sans toucher à Windows).
-- 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
kanze
Fabien LE LEZ wrote:
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.
Il y a des options Windows pour être « Posix compliant ». Parce que c'est exigé par certaines administrations américaines. De prèsque je comprends, elles ne sont pas réelement utilisables.
CygWin a aussi une bibliothèque « compatible Posix » pour Windows. D'après le peu que j'ai vu, les performances ne sont pas très brillantes non plus.
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.
Surtout parce qu'il existe des bibliothèques qui font le boulot pour toi.
Si tu écris un programme graphique sous Solaris, en te servant directement des interfaces Open Desktop de Solaris, tu aurais des problèmes à le porter même à Linux. Même Motif risque de poser des problèmes. C'est pareil, à un moindre degrée, si tu fais des choses limites avec des sockets, et sans doute pour beaucoup d'autres choses.
Si dans ton programme, tu t'es servi de wxWidgets, de boost threads, et que sais-je pour les sockets, c'est possible que tu peux le porter même à Windows sans changer une seule ligne de code.
Si tu as fait le mauvais choix au départ, un portage va poser plutôt de problèmes.
Est-ce qu'il existe d'autres OS, au fait, en-dehors de l'embarqué (et des musées) ?
Bien sur. IBM en a pour les 390, et OpenVMS est loin d'être mort. Mais c'est vrai que pour beaucoup d'applications, Windows et les Unix « mainstream » (Linux, Solaris, AIX, HP/UX, et peut-être les Unix de SGI ou de Compaq ancien Digital) suffisent largement en ce qui concerne la portabilité. Et qu'à part Linux, les Unix là s'alignent plus ou moins sur les normes Open System.
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...
Certes. J'ai donné Mozilla comme exemple extrème -- leur but, c'est que tu peux télécharger les sources, et que ça marche chez toi, quelque soit le compilateur et le système que tu as. Si tu livres toi-même les exécutables, et que le client n'a pas à compiler chez lui, c'est déjà beaucoup plus facile à gerer ; s'il y a un problème avec un environement donné, tu as automatiquement accès à l'environement exact du build.
-- 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 wrote:
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.
Il y a des options Windows pour être « Posix compliant ». Parce
que c'est exigé par certaines administrations américaines. De
prèsque je comprends, elles ne sont pas réelement utilisables.
CygWin a aussi une bibliothèque « compatible Posix » pour
Windows. D'après le peu que j'ai vu, les performances ne sont
pas très brillantes non plus.
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.
Surtout parce qu'il existe des bibliothèques qui font le boulot
pour toi.
Si tu écris un programme graphique sous Solaris, en te servant
directement des interfaces Open Desktop de Solaris, tu aurais
des problèmes à le porter même à Linux. Même Motif risque de
poser des problèmes. C'est pareil, à un moindre degrée, si tu
fais des choses limites avec des sockets, et sans doute pour
beaucoup d'autres choses.
Si dans ton programme, tu t'es servi de wxWidgets, de boost
threads, et que sais-je pour les sockets, c'est possible que tu
peux le porter même à Windows sans changer une seule ligne de
code.
Si tu as fait le mauvais choix au départ, un portage va poser
plutôt de problèmes.
Est-ce qu'il existe d'autres OS, au fait, en-dehors de
l'embarqué (et des musées) ?
Bien sur. IBM en a pour les 390, et OpenVMS est loin d'être
mort. Mais c'est vrai que pour beaucoup d'applications, Windows
et les Unix « mainstream » (Linux, Solaris, AIX, HP/UX, et
peut-être les Unix de SGI ou de Compaq ancien Digital)
suffisent largement en ce qui concerne la portabilité. Et qu'à
part Linux, les Unix là s'alignent plus ou moins sur les normes
Open System.
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...
Certes. J'ai donné Mozilla comme exemple extrème -- leur but,
c'est que tu peux télécharger les sources, et que ça marche chez
toi, quelque soit le compilateur et le système que tu as. Si tu
livres toi-même les exécutables, et que le client n'a pas à
compiler chez lui, c'est déjà beaucoup plus facile à gerer ;
s'il y a un problème avec un environement donné, tu as
automatiquement accès à l'environement exact du build.
--
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
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.
Il y a des options Windows pour être « Posix compliant ». Parce que c'est exigé par certaines administrations américaines. De prèsque je comprends, elles ne sont pas réelement utilisables.
CygWin a aussi une bibliothèque « compatible Posix » pour Windows. D'après le peu que j'ai vu, les performances ne sont pas très brillantes non plus.
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.
Surtout parce qu'il existe des bibliothèques qui font le boulot pour toi.
Si tu écris un programme graphique sous Solaris, en te servant directement des interfaces Open Desktop de Solaris, tu aurais des problèmes à le porter même à Linux. Même Motif risque de poser des problèmes. C'est pareil, à un moindre degrée, si tu fais des choses limites avec des sockets, et sans doute pour beaucoup d'autres choses.
Si dans ton programme, tu t'es servi de wxWidgets, de boost threads, et que sais-je pour les sockets, c'est possible que tu peux le porter même à Windows sans changer une seule ligne de code.
Si tu as fait le mauvais choix au départ, un portage va poser plutôt de problèmes.
Est-ce qu'il existe d'autres OS, au fait, en-dehors de l'embarqué (et des musées) ?
Bien sur. IBM en a pour les 390, et OpenVMS est loin d'être mort. Mais c'est vrai que pour beaucoup d'applications, Windows et les Unix « mainstream » (Linux, Solaris, AIX, HP/UX, et peut-être les Unix de SGI ou de Compaq ancien Digital) suffisent largement en ce qui concerne la portabilité. Et qu'à part Linux, les Unix là s'alignent plus ou moins sur les normes Open System.
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...
Certes. J'ai donné Mozilla comme exemple extrème -- leur but, c'est que tu peux télécharger les sources, et que ça marche chez toi, quelque soit le compilateur et le système que tu as. Si tu livres toi-même les exécutables, et que le client n'a pas à compiler chez lui, c'est déjà beaucoup plus facile à gerer ; s'il y a un problème avec un environement donné, tu as automatiquement accès à l'environement exact du build.
-- 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
kanze
wrote:
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 ?
Ça dépend en fait de la bibliothèque. Grosso modo, il y a trois catégories :
-- Celles qui sont intimement liées au langage : en C++, c'est surtout <new>, <typeinfo> et <numeric_limits>, en C, il y a aussi <stdarg.h>, <limits.h> et <float.h>.
Réalistiquement, je ne crois pas qu'ils se passent de new ou de INT_MAX. Mais ils interdisent bien le RTTI (<typeinfo>), les exceptions at les var args <stdarg.h>. Et ils restreignent énormement l'utilisation des templates, ce qui fait qu'on doit pouvoir s'en tirer avec <limits.h> plutôt que <limits>. (Jusqu'il y a un an environ, je me servais encore regulièrement d'un compilateur qui ne supportait pas <limits>.)
-- Celles dont il faut des requêtes système dans l'implémentation, du genre iostream. Pour ne pas s'en servir, il faut écrire ses propres bibliothèques, avec des parties dépendantes de l'implémentation. Mes ces parties peuvent être bien petites, et gerer uniquement par une équipe limitée. Et l'interface que tu présentes a probablement moins de variations que ce qu'on trouve dans iostream, ou même dans <stdio.h>. (Dans la pratique, l'utilisation de iostream pose de gros problèmes de portabilité, surtout si tu veux supporter des compilateurs pas trop moderne, comme g++ 2.95.2.)
-- Celles qui peuvent s'écrire complètement en C++ standard. C'est le cas de toute la STL, par exemple. Alors, tu fournis tes propres versions, ou une fonctionnalité équivalente, et tu es libre de la bibliothèque standard. L'avantage, c'est que tu es libre des variations que tu pourras trouver dans la bibliothèque standard.
La contrapartie, surtout en ce qui concerne les deux derniers points, c'est qu'il exige beaucoup plus de travail. Au moins de tenir vraiment à supporter tous les compilateurs existants, je doute réelement que ça vaut la peine. Même dans leur cas, je crois que je ferais un tri -- peut-être pas de iostream, mais j'ai du mal à imaginer un problème avec stdio.
-- 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
Dominique.Micollet@u-bourgogne.fr.fr.fr wrote:
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 ?
Ça dépend en fait de la bibliothèque. Grosso modo, il y a trois
catégories :
-- Celles qui sont intimement liées au langage : en C++, c'est
surtout <new>, <typeinfo> et <numeric_limits>, en C, il y a
aussi <stdarg.h>, <limits.h> et <float.h>.
Réalistiquement, je ne crois pas qu'ils se passent de new ou
de INT_MAX. Mais ils interdisent bien le RTTI (<typeinfo>),
les exceptions at les var args <stdarg.h>. Et ils
restreignent énormement l'utilisation des templates, ce qui
fait qu'on doit pouvoir s'en tirer avec <limits.h> plutôt
que <limits>. (Jusqu'il y a un an environ, je me servais
encore regulièrement d'un compilateur qui ne supportait pas
<limits>.)
-- Celles dont il faut des requêtes système dans
l'implémentation, du genre iostream. Pour ne pas s'en
servir, il faut écrire ses propres bibliothèques, avec des
parties dépendantes de l'implémentation. Mes ces parties
peuvent être bien petites, et gerer uniquement par une
équipe limitée. Et l'interface que tu présentes a
probablement moins de variations que ce qu'on trouve dans
iostream, ou même dans <stdio.h>. (Dans la pratique,
l'utilisation de iostream pose de gros problèmes de
portabilité, surtout si tu veux supporter des compilateurs
pas trop moderne, comme g++ 2.95.2.)
-- Celles qui peuvent s'écrire complètement en C++ standard.
C'est le cas de toute la STL, par exemple. Alors, tu
fournis tes propres versions, ou une fonctionnalité
équivalente, et tu es libre de la bibliothèque standard.
L'avantage, c'est que tu es libre des variations que tu
pourras trouver dans la bibliothèque standard.
La contrapartie, surtout en ce qui concerne les deux derniers
points, c'est qu'il exige beaucoup plus de travail. Au moins de
tenir vraiment à supporter tous les compilateurs existants, je
doute réelement que ça vaut la peine. Même dans leur cas, je
crois que je ferais un tri -- peut-être pas de iostream, mais
j'ai du mal à imaginer un problème avec stdio.
--
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
Juste pour ma culture : on fait comment pour se passer des bibliothèques standards ?
Ça dépend en fait de la bibliothèque. Grosso modo, il y a trois catégories :
-- Celles qui sont intimement liées au langage : en C++, c'est surtout <new>, <typeinfo> et <numeric_limits>, en C, il y a aussi <stdarg.h>, <limits.h> et <float.h>.
Réalistiquement, je ne crois pas qu'ils se passent de new ou de INT_MAX. Mais ils interdisent bien le RTTI (<typeinfo>), les exceptions at les var args <stdarg.h>. Et ils restreignent énormement l'utilisation des templates, ce qui fait qu'on doit pouvoir s'en tirer avec <limits.h> plutôt que <limits>. (Jusqu'il y a un an environ, je me servais encore regulièrement d'un compilateur qui ne supportait pas <limits>.)
-- Celles dont il faut des requêtes système dans l'implémentation, du genre iostream. Pour ne pas s'en servir, il faut écrire ses propres bibliothèques, avec des parties dépendantes de l'implémentation. Mes ces parties peuvent être bien petites, et gerer uniquement par une équipe limitée. Et l'interface que tu présentes a probablement moins de variations que ce qu'on trouve dans iostream, ou même dans <stdio.h>. (Dans la pratique, l'utilisation de iostream pose de gros problèmes de portabilité, surtout si tu veux supporter des compilateurs pas trop moderne, comme g++ 2.95.2.)
-- Celles qui peuvent s'écrire complètement en C++ standard. C'est le cas de toute la STL, par exemple. Alors, tu fournis tes propres versions, ou une fonctionnalité équivalente, et tu es libre de la bibliothèque standard. L'avantage, c'est que tu es libre des variations que tu pourras trouver dans la bibliothèque standard.
La contrapartie, surtout en ce qui concerne les deux derniers points, c'est qu'il exige beaucoup plus de travail. Au moins de tenir vraiment à supporter tous les compilateurs existants, je doute réelement que ça vaut la peine. Même dans leur cas, je crois que je ferais un tri -- peut-être pas de iostream, mais j'ai du mal à imaginer un problème avec stdio.
-- 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
kanze
wrote:
In article , Fabien LE LEZ writes:
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.
Bien.
Mais alors comment cela peut il régler le problème de bibliothèques standard incompatibles avec les divers compilateurs : est ce que sont fournies des encapsulations qui prévoient tous les cas ?
Soit leur encapsulation ne prévoit qu'une partie des fonctionnalités, qu'on est sûr de pouvoir implémenter partout, soit ils implémentent eux-même la fonctionnalité qu'ils ont définie directement, au moyen des appels système ou du C++ ultra-standard.
Et si j'ai besoin d'une bibliothèque standard qui n'a pas été encapsulée, j'imagine qu'avant de l'utiliser, je dois l'encapsuler et la faire valider ?
J'imagine tout simplement que tu n'en as pas droit.
On n'en as jamais « besoin ». C'est simplement que parfois, c'est bien commode. C'est bien plus commode, par exemple, d'écrire maFichier << unDouble, que d'implémenter tout le formattage des doubles soi-même, ainsi que la bufferisation et l'accès aux fichiers à partir des requêtes de base du système. (Mais note que je n'utilise très peu les fstream dans mes applications. Je me sers prèsque toujours des interfaces système de bas niveau, parce que j'ai besoin des fonctionnalités qui ne sont pas disponible dans les fstream.)
-- 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
Dominique.Micollet@u-bourgogne.fr.fr.fr wrote:
In article <lth1m156chej97hij0cp4vfhekbh228oj3@4ax.com>,
Fabien LE LEZ <gramster@gramster.com> writes:
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.
Bien.
Mais alors comment cela peut il régler le problème de
bibliothèques standard incompatibles avec les divers
compilateurs : est ce que sont fournies des encapsulations qui
prévoient tous les cas ?
Soit leur encapsulation ne prévoit qu'une partie des
fonctionnalités, qu'on est sûr de pouvoir implémenter partout,
soit ils implémentent eux-même la fonctionnalité qu'ils ont
définie directement, au moyen des appels système ou du C++
ultra-standard.
Et si j'ai besoin d'une bibliothèque standard qui n'a pas été
encapsulée, j'imagine qu'avant de l'utiliser, je dois
l'encapsuler et la faire valider ?
J'imagine tout simplement que tu n'en as pas droit.
On n'en as jamais « besoin ». C'est simplement que parfois,
c'est bien commode. C'est bien plus commode, par exemple,
d'écrire maFichier << unDouble, que d'implémenter tout le
formattage des doubles soi-même, ainsi que la bufferisation et
l'accès aux fichiers à partir des requêtes de base du système.
(Mais note que je n'utilise très peu les fstream dans mes
applications. Je me sers prèsque toujours des interfaces système
de bas niveau, parce que j'ai besoin des fonctionnalités qui ne
sont pas disponible dans les fstream.)
--
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
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.
Bien.
Mais alors comment cela peut il régler le problème de bibliothèques standard incompatibles avec les divers compilateurs : est ce que sont fournies des encapsulations qui prévoient tous les cas ?
Soit leur encapsulation ne prévoit qu'une partie des fonctionnalités, qu'on est sûr de pouvoir implémenter partout, soit ils implémentent eux-même la fonctionnalité qu'ils ont définie directement, au moyen des appels système ou du C++ ultra-standard.
Et si j'ai besoin d'une bibliothèque standard qui n'a pas été encapsulée, j'imagine qu'avant de l'utiliser, je dois l'encapsuler et la faire valider ?
J'imagine tout simplement que tu n'en as pas droit.
On n'en as jamais « besoin ». C'est simplement que parfois, c'est bien commode. C'est bien plus commode, par exemple, d'écrire maFichier << unDouble, que d'implémenter tout le formattage des doubles soi-même, ainsi que la bufferisation et l'accès aux fichiers à partir des requêtes de base du système. (Mais note que je n'utilise très peu les fstream dans mes applications. Je me sers prèsque toujours des interfaces système de bas niveau, parce que j'ai besoin des fonctionnalités qui ne sont pas disponible dans les fstream.)
-- 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 28 Oct 2005 01:04:42 -0700, "kanze" :
j'ai du mal à imaginer un problème avec stdio.
Exemple de problème possible : une mauvaise gestion du multithread.
On 28 Oct 2005 01:04:42 -0700, "kanze" <kanze@gabi-soft.fr>:
j'ai du mal à imaginer un problème avec stdio.
Exemple de problème possible : une mauvaise gestion du multithread.
Exemple de problème possible : une mauvaise gestion du multithread.
Fabien LE LEZ
À ma réflexion :
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.
James Kanze répond (28 Oct 2005 00:27:12 -0700) :
[...]Je ne sais pas ce que font la majorité des programmeurs, mais dans la pratique, il y a encore énormement de choses qu'un PC ne sait pas faire,
En gros, si j'ai bien saisi, tu dis qu'il y a beaucoup de programmeurs Unix (ou autres OS différents de Windows). Ce qui ne contredit pas ce que j'ai dit : la plupart des gens qui programment en Visual C++ ne se rendent pas compte qu'il existe d'autres compilateurs (même sous Windows), la plupart des programmeurs g++ sous Linux ne se rendent pas compte qu'il peut exister d'autres compilateurs, etc.
À ma réflexion :
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.
James Kanze répond (28 Oct 2005 00:27:12 -0700) :
[...]Je ne sais pas ce que font la majorité des
programmeurs, mais dans la pratique, il y a encore énormement de
choses qu'un PC ne sait pas faire,
En gros, si j'ai bien saisi, tu dis qu'il y a beaucoup de programmeurs
Unix (ou autres OS différents de Windows). Ce qui ne contredit pas ce
que j'ai dit : la plupart des gens qui programment en Visual C++ ne se
rendent pas compte qu'il existe d'autres compilateurs (même sous
Windows), la plupart des programmeurs g++ sous Linux ne se rendent pas
compte qu'il peut exister d'autres compilateurs, etc.
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.
James Kanze répond (28 Oct 2005 00:27:12 -0700) :
[...]Je ne sais pas ce que font la majorité des programmeurs, mais dans la pratique, il y a encore énormement de choses qu'un PC ne sait pas faire,
En gros, si j'ai bien saisi, tu dis qu'il y a beaucoup de programmeurs Unix (ou autres OS différents de Windows). Ce qui ne contredit pas ce que j'ai dit : la plupart des gens qui programment en Visual C++ ne se rendent pas compte qu'il existe d'autres compilateurs (même sous Windows), la plupart des programmeurs g++ sous Linux ne se rendent pas compte qu'il peut exister d'autres compilateurs, etc.
Fabien LE LEZ
On 28 Oct 2005 00:27:12 -0700, "kanze" :
Il ne me serait jamais venu à l'ésprit d'utiliser g++ sous Windows.
Ben moi je suis obligé, ne serait-ce que pour pouvoir utiliser sous Windows des bouts de codes programmés sous Linux en g++.
En ce qui concerne les DLL's, j'ai quand même mes doutes. Est-ce que les versions Windows de g++ aient des extensions Microsoft qui servent dans ces cas-là ?
Disons que manifestement, tant qu'on s'en tient aux bases (exportation de classes abstraites et de fonctions "extern "C"", et passage de POD par référence), ça marche.
On 28 Oct 2005 00:27:12 -0700, "kanze" <kanze@gabi-soft.fr>:
Il ne me serait jamais venu à l'ésprit
d'utiliser g++ sous Windows.
Ben moi je suis obligé, ne serait-ce que pour pouvoir utiliser sous
Windows des bouts de codes programmés sous Linux en g++.
En ce qui concerne les DLL's, j'ai
quand même mes doutes. Est-ce que les versions Windows de g++
aient des extensions Microsoft qui servent dans ces cas-là ?
Disons que manifestement, tant qu'on s'en tient aux bases (exportation
de classes abstraites et de fonctions "extern "C"", et passage de POD
par référence), ça marche.
Il ne me serait jamais venu à l'ésprit d'utiliser g++ sous Windows.
Ben moi je suis obligé, ne serait-ce que pour pouvoir utiliser sous Windows des bouts de codes programmés sous Linux en g++.
En ce qui concerne les DLL's, j'ai quand même mes doutes. Est-ce que les versions Windows de g++ aient des extensions Microsoft qui servent dans ces cas-là ?
Disons que manifestement, tant qu'on s'en tient aux bases (exportation de classes abstraites et de fonctions "extern "C"", et passage de POD par référence), ça marche.
kanze
Fabien LE LEZ wrote:
À ma réflexion :
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.
James Kanze répond (28 Oct 2005 00:27:12 -0700) :
[...]Je ne sais pas ce que font la majorité des programmeurs, mais dans la pratique, il y a encore énormement de choses qu'un PC ne sait pas faire,
En gros, si j'ai bien saisi, tu dis qu'il y a beaucoup de programmeurs Unix (ou autres OS différents de Windows). Ce qui ne contredit pas ce que j'ai dit : la plupart des gens qui programment en Visual C++ ne se rendent pas compte qu'il existe d'autres compilateurs (même sous Windows), la plupart des programmeurs g++ sous Linux ne se rendent pas compte qu'il peut exister d'autres compilateurs, etc.
Qu'un programmeur Windows ne sache pas qu'il existe autre chose, je peux le conçois à la rigueur (encore que...). Un programmeur Unix sait toujours 1) qu'il existe à la fois le compilateur natif (Sun CC, aCC, xlC...) et g++, et 2) qu'il existe un autre système d'exploitation, qui s'appelle Windows (et il s'en doute bien qu'il y a un compilateur aussi).
-- 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 wrote:
À ma réflexion :
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.
James Kanze répond (28 Oct 2005 00:27:12 -0700) :
[...]Je ne sais pas ce que font la majorité des programmeurs,
mais dans la pratique, il y a encore énormement de choses
qu'un PC ne sait pas faire,
En gros, si j'ai bien saisi, tu dis qu'il y a beaucoup de
programmeurs Unix (ou autres OS différents de Windows). Ce qui
ne contredit pas ce que j'ai dit : la plupart des gens qui
programment en Visual C++ ne se rendent pas compte qu'il
existe d'autres compilateurs (même sous Windows), la plupart
des programmeurs g++ sous Linux ne se rendent pas compte qu'il
peut exister d'autres compilateurs, etc.
Qu'un programmeur Windows ne sache pas qu'il existe autre chose,
je peux le conçois à la rigueur (encore que...). Un programmeur
Unix sait toujours 1) qu'il existe à la fois le compilateur
natif (Sun CC, aCC, xlC...) et g++, et 2) qu'il existe un autre
système d'exploitation, qui s'appelle Windows (et il s'en doute
bien qu'il y a un compilateur aussi).
--
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
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.
James Kanze répond (28 Oct 2005 00:27:12 -0700) :
[...]Je ne sais pas ce que font la majorité des programmeurs, mais dans la pratique, il y a encore énormement de choses qu'un PC ne sait pas faire,
En gros, si j'ai bien saisi, tu dis qu'il y a beaucoup de programmeurs Unix (ou autres OS différents de Windows). Ce qui ne contredit pas ce que j'ai dit : la plupart des gens qui programment en Visual C++ ne se rendent pas compte qu'il existe d'autres compilateurs (même sous Windows), la plupart des programmeurs g++ sous Linux ne se rendent pas compte qu'il peut exister d'autres compilateurs, etc.
Qu'un programmeur Windows ne sache pas qu'il existe autre chose, je peux le conçois à la rigueur (encore que...). Un programmeur Unix sait toujours 1) qu'il existe à la fois le compilateur natif (Sun CC, aCC, xlC...) et g++, et 2) qu'il existe un autre système d'exploitation, qui s'appelle Windows (et il s'en doute bien qu'il y a un compilateur aussi).
-- 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
