Tout dépend de ce que tu entends par portabilité et là aussi c'est un grand débat...
Pour moi, il y a deux niveaux de portabilité. Le premier, celui auquel on pence le plus souvent consiste à dire qu'un programme est portable si on peut le faire tourner sur pas mal de platformes courantes que le commun des mortels utilise courrament et consciament. Donc en gros sur des ordinateurs au sens madame michu du terme avec un OS au sens au moins 1% de geek en a déjà entendu le nom.
Dans ce cas là, java est portable tout comme du C++ et je pense Qt ou la GLib. De même pas mal de langage de scripts vont entrer dans cette catégorie.
Le deuxième, celui auquel je faisait référence ici, concerne un bien plus grand nombre de machine et d'OS puisqu'il englobe tous les systèmes capable d'exécuter un programme, même les petits micro controleur ou autre. Ça concerne peut-être moins de monde ici, mais de manière globale ça concerne énormément de monde...
Dans ce cas la être portable ça eut dire être compilable sur un max de platformes très hétérogènes. Et pour ces platformes, en général un compilateur ansi/C est la première chose qui soit disponible pour compiler du code en dehors de l'assembleur ou d'un langage spécifique à la platforme.
Donc, la grande majorité du temps, un code portable dans ce sens c'est un code en ansi/C et la seule chose que ce code peut utiliser c'est des bibliothèques elles-aussi en ansi/C.
C'est ça qui à poussé les auteurs du langage Lua, par exemple, à le coder en ansi/C pur. Ils ont conçu le langage pour leur besoin à la base et les sytsème sur lesquels il était utilisé était très hétérogène, il n'avait donc pas trop le choix.
Le revert de la médaille c'est que c'est aussi un langage relativement pauvre en librairies fournies de base, beaucoup de chose sont soit impossible en c pur, soit tros complexe à réimplémenter et la aussi laissées au soins de lib externe qui ne sont plus forcément portable.
À mon avis il y a surtout de moins en moins de nouveaux projets qui commencent en C. Déja pour faire une interface graphique t'es obligé de rajouter une bibliothèque, genre glib ou Qt.
beaucoup de projets n'ont pas besoin d'interface graphique et ce sont en plus ceux qui sont le plus souvent codé en C...
Beaucoup de programme sont d'ailleur codé de cette manière, un coeur qui fait le gros du boulot codé en C ou dans un autre langage suffisament portable pour la tâche en utilisant le moins de lib non portables possible. (pas toujours évident)
Et à côter une interface graphique qui appelle l'autre code portable sous la forme d'un programme ou d'une lib.
Coder une interface graphique en C n'a pour moi que peu d'interet car il y a des langage ou c'est beaucoup plus simple, bien moins sujet au bugs et vu que l'interface graphique impose déjà des contraintes sur la portabilité autant faire au plus simple.
[^] # Re: Humm...
Posté par beagf . En réponse à la dépêche Sortie de la version 2.11 de la bibliothèque standard C GNU (glibc). Évalué à 3.
Pour moi, il y a deux niveaux de portabilité. Le premier, celui auquel on pence le plus souvent consiste à dire qu'un programme est portable si on peut le faire tourner sur pas mal de platformes courantes que le commun des mortels utilise courrament et consciament. Donc en gros sur des ordinateurs au sens madame michu du terme avec un OS au sens au moins 1% de geek en a déjà entendu le nom.
Dans ce cas là, java est portable tout comme du C++ et je pense Qt ou la GLib. De même pas mal de langage de scripts vont entrer dans cette catégorie.
Le deuxième, celui auquel je faisait référence ici, concerne un bien plus grand nombre de machine et d'OS puisqu'il englobe tous les systèmes capable d'exécuter un programme, même les petits micro controleur ou autre. Ça concerne peut-être moins de monde ici, mais de manière globale ça concerne énormément de monde...
Dans ce cas la être portable ça eut dire être compilable sur un max de platformes très hétérogènes. Et pour ces platformes, en général un compilateur ansi/C est la première chose qui soit disponible pour compiler du code en dehors de l'assembleur ou d'un langage spécifique à la platforme.
Donc, la grande majorité du temps, un code portable dans ce sens c'est un code en ansi/C et la seule chose que ce code peut utiliser c'est des bibliothèques elles-aussi en ansi/C.
C'est ça qui à poussé les auteurs du langage Lua, par exemple, à le coder en ansi/C pur. Ils ont conçu le langage pour leur besoin à la base et les sytsème sur lesquels il était utilisé était très hétérogène, il n'avait donc pas trop le choix.
Le revert de la médaille c'est que c'est aussi un langage relativement pauvre en librairies fournies de base, beaucoup de chose sont soit impossible en c pur, soit tros complexe à réimplémenter et la aussi laissées au soins de lib externe qui ne sont plus forcément portable.
À mon avis il y a surtout de moins en moins de nouveaux projets qui commencent en C. Déja pour faire une interface graphique t'es obligé de rajouter une bibliothèque, genre glib ou Qt.
beaucoup de projets n'ont pas besoin d'interface graphique et ce sont en plus ceux qui sont le plus souvent codé en C...
Beaucoup de programme sont d'ailleur codé de cette manière, un coeur qui fait le gros du boulot codé en C ou dans un autre langage suffisament portable pour la tâche en utilisant le moins de lib non portables possible. (pas toujours évident)
Et à côter une interface graphique qui appelle l'autre code portable sous la forme d'un programme ou d'une lib.
Coder une interface graphique en C n'a pour moi que peu d'interet car il y a des langage ou c'est beaucoup plus simple, bien moins sujet au bugs et vu que l'interface graphique impose déjà des contraintes sur la portabilité autant faire au plus simple.