On voit souvent des "quel linux choisir ?", des "pourquoi linux ?" etc.
Mais finalement à devoir choisir entre la peste (du côté de chez MS) et
la grippe (notre bon vieux nunux), celà ne vous arrive pas le matin en
vous réveillant de vous dire que les programmes qui font fonctionner
votre machines ne sont que des bidouillages plus ou moins réussis ?
Regardez les codes sources d'un programme en C. Même le code d'un bon
programmeur n'est rempli que d'horreurs. Ce fameux "void" : c'est quoi
cette abomination de la programmation ? Il n'y a aucune sémantique
valable là derrière. D'ailleurs les types en C n'ont de type que le nom.
Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de
10 éléments. Ce langage surestime beaucoup les capacités des personnes
qui vont l'utiliser. Une telle chose ne doit pas être possible. Comment
imaginer que ce genre de choses peut être voulu par le programmeur ?
Je pense que vous avez déjà vu du JAVA. Mais c'est à gerber cet
emboîtement de new, cette masse colossale de classes à faire pour faire
trois fois rien ! J'ose même pas imaginer la quantité de calculs
inutiles faits par la machine pour gérer ces merdes. D'accord il y a de
l'optimisation, mais c'est loin d'être suffisant.
Dans le temps les programmes étaient bidouillés parce qu'il n'y avait
pas assez de mémoire : par exemple on utilisait une variable pour
stocker deux informations. Maintenant l'horreur est à l'autre extrême :
on a tellement de mémoire de disponible que l'on utilise trop. En C :
tant pis c'est perdu. Un trou de mémoire ? Tant que le pc doit pas
redémarrer toutes les heures à cause de ça on s'en fout. En JAVA : il y
a le ramasse miettes alors on peut bouffer de la mémoire : c'est pô grave.
Dès que les programmes ont commencé à ne plus rentrer sur une disquette
ils sont devenus beaucoup trop compliqués pour fonctionner correctement.
On en vient à une époque où on trouve acceptable un programme quand il a
moins de cent bugs alors que rien que le fait de consommer trop de
ressources fait que le programme n'est pas bon. Aujourd'hui on nous
parle de .NET et de merdouilles dans le genre. A quoi ça sert de se
lancer dans la création de langages qui se copient les uns les autres.
C, C++, JAVA, Pascal : c'est la même chose, la même façon de penser. Et
c'est une manière de penser qui pousse à faire des fautes.
Bref l'informatique ne va pas fort.
Et après ce sont mes propos qui n'ont rien à faire ici. Vous voulez quoi que je vienne dire toute mon admiration sur linux, c'est ça un débat ? J'aime bien Linux. Mais c'est loin d'être bien foutu. Et pour être bien foutu ça devrait être fait dans un langage bien foutu. Et par des gens qui pensent autrement qu'en impératif. Mais peut être avez vous des arguments pour me prouver que le C est un joli langage.
L'objectif de Linux est d'être un Unix, ce qui impose l'utilisation du langage C, pour des raisons historiques. Écrire un OS dans un autre langage est sans doute possible, mais ce ne sera plus un Unix, mais autre chose.
-- Richard
Et après ce sont mes propos qui n'ont rien à faire ici. Vous voulez quoi
que je vienne dire toute mon admiration sur linux, c'est ça un débat ?
J'aime bien Linux. Mais c'est loin d'être bien foutu. Et pour être bien
foutu ça devrait être fait dans un langage bien foutu. Et par des gens
qui pensent autrement qu'en impératif. Mais peut être avez vous des
arguments pour me prouver que le C est un joli langage.
L'objectif de Linux est d'être un Unix, ce qui impose l'utilisation du
langage C, pour des raisons historiques.
Écrire un OS dans un autre langage est sans doute possible, mais ce ne
sera plus un Unix, mais autre chose.
Et après ce sont mes propos qui n'ont rien à faire ici. Vous voulez quoi que je vienne dire toute mon admiration sur linux, c'est ça un débat ? J'aime bien Linux. Mais c'est loin d'être bien foutu. Et pour être bien foutu ça devrait être fait dans un langage bien foutu. Et par des gens qui pensent autrement qu'en impératif. Mais peut être avez vous des arguments pour me prouver que le C est un joli langage.
L'objectif de Linux est d'être un Unix, ce qui impose l'utilisation du langage C, pour des raisons historiques. Écrire un OS dans un autre langage est sans doute possible, mais ce ne sera plus un Unix, mais autre chose.
-- Richard
Richard Delorme
On croirait lire du luc2. Un void* ne represente pas du vide, ca represente un pointeur sur une zone de memoire dont on ne veut pas se soucier du type de donnees qui y sont stockees.
On ne veut pas se soucier du type ! Mais bon sang c'est à cause de son système de non-types que le C est un non-langage ! Sachez que c'est grâce au typage statique que Caml est un langage évolué. Le mécanisme de typage est une preuve du programme. Vous pouvez rechercher lambda-calcul et isomorphisme de Curry-Howard sur le net.
Avec un minimum d'effort, ça marche aussi pour le C : http://www.cl.cam.ac.uk/~mn200/PhD/
-- Richard
On croirait lire du luc2. Un void* ne represente pas du vide, ca
represente un pointeur sur une zone de memoire dont on ne veut pas se
soucier du type de donnees qui y sont stockees.
On ne veut pas se soucier du type ! Mais bon sang c'est à cause de son
système de non-types que le C est un non-langage ! Sachez que c'est
grâce au typage statique que Caml est un langage évolué. Le mécanisme de
typage est une preuve du programme. Vous pouvez rechercher lambda-calcul
et isomorphisme de Curry-Howard sur le net.
Avec un minimum d'effort, ça marche aussi pour le C :
http://www.cl.cam.ac.uk/~mn200/PhD/
On croirait lire du luc2. Un void* ne represente pas du vide, ca represente un pointeur sur une zone de memoire dont on ne veut pas se soucier du type de donnees qui y sont stockees.
On ne veut pas se soucier du type ! Mais bon sang c'est à cause de son système de non-types que le C est un non-langage ! Sachez que c'est grâce au typage statique que Caml est un langage évolué. Le mécanisme de typage est une preuve du programme. Vous pouvez rechercher lambda-calcul et isomorphisme de Curry-Howard sur le net.
Avec un minimum d'effort, ça marche aussi pour le C : http://www.cl.cam.ac.uk/~mn200/PhD/
-- Richard
Joe Cool
Joe Cool wrote:
Quand on arrive à l'argument d'autorité, c'est qu'on à plus rien à dire.
Vous êtes dos au mur.
"vous êtes dos au mur"... Personne n'est accusé de quoi que ce soit ici, que je sache.
C'est surtout qu'en disant "tout est à mettre à la poubelle" sans proposer d'alternative, ça ne fait pas avancer le débat...
C'est amusant ça : quand on met le C à la poubelle, on met « tout » à la poubelle, et quand on supprime le C, on considère qu'il n'y a plus d'alternative.
Caml est inadapté à la 'programmation système',
C'est faux.
le C (d'après vous) est une horreur
C'est objectivement une horreur, cela ne dépend pas de moi, le C est une abomination tout seul.
-- Joe Cool
Joe Cool wrote:
Quand on arrive à l'argument d'autorité, c'est qu'on à plus rien à dire.
Vous êtes dos au mur.
"vous êtes dos au mur"... Personne n'est accusé de quoi que ce soit ici,
que je sache.
C'est surtout qu'en disant "tout est à mettre à la poubelle" sans
proposer d'alternative, ça ne fait pas avancer le débat...
C'est amusant ça : quand on met le C à la poubelle, on met « tout » à la
poubelle, et quand on supprime le C, on considère qu'il n'y a plus
d'alternative.
Caml est inadapté à la 'programmation système',
C'est faux.
le C (d'après vous) est une horreur
C'est objectivement une horreur, cela ne dépend pas de moi, le C est une
abomination tout seul.
Quand on arrive à l'argument d'autorité, c'est qu'on à plus rien à dire.
Vous êtes dos au mur.
"vous êtes dos au mur"... Personne n'est accusé de quoi que ce soit ici, que je sache.
C'est surtout qu'en disant "tout est à mettre à la poubelle" sans proposer d'alternative, ça ne fait pas avancer le débat...
C'est amusant ça : quand on met le C à la poubelle, on met « tout » à la poubelle, et quand on supprime le C, on considère qu'il n'y a plus d'alternative.
Caml est inadapté à la 'programmation système',
C'est faux.
le C (d'après vous) est une horreur
C'est objectivement une horreur, cela ne dépend pas de moi, le C est une abomination tout seul.
-- Joe Cool
Joe Cool
Contrairement à ce que l'on croit, la portabilité d'un langage est uniquement déterminée par la qualité de sa spécification. Un langage d'assemblage est portable car sa sémantique est univoque, alors que la liste des « undefined behaviors » du C fait 20 pages.
Permettez-moi donc de traiter de con tout ceux qui affirment péremptoirement que le C est portable.
Justement, les comportements indéfinis sont là pour faciliter la portabilité du langage sur des architectures très différentes.
???
Vous rendez-vous compte de ce que vous dites ?
Oui et je maintiens. D'après le rationale, qui explique les intentions de la norme du langage, les comportements indéfinis sont bien là pour facilité les implémentations :
http://www.lysator.liu.se/c/rat/a.html#1-6
C'est alors un aveu d'incompétence de la part des rédacteurs de la norme. Autant faire un langage entièrement composé de undefined behavior, il sera d'autant plus portable et efficace.
Le résultat est que qu'il existe des compilateurs C pour presque tout ce qui a un processeur, ce qui est loin d'être le cas pour les autres langages.
La belle affaire : le C est le langage soutenu majoritairement par l'industrie, qui seule à le pouvoir d'implémenter un mauvais langage sur toutes les architectures. Ce n'est pas parce que tout le monde fait une chose que ce n'est pas une mauvaise chose.
L'existence d'un compilateur sur chaque machine existante ne rend pas un langage plus portable, sinon tout est portable : il suffit d'en faire un compilateur.
Il y a un problème de faisabilité. Les comportements indéfinis sont là pour rendre le portage faisable. Par exemple Java n'a aucun comportement indéfini mais existe sur très peu d'architectures, et n'existera jamais pour MS-DOS, par exemple.
Ce n'est qu'une question de politique. Un langage portable est un langage qui ne contient aucun comportement indéfini. Sinon je peux décider d'appeler « assemblage » l'ensemble des langages d'assemblage, prétendre qu'ils sont tous identiques, à quelques comportement indéfinis près, puis faire croire que ça rend « assemblage » portable, efficace, simple, sûr, etc.
C'est n'importe quoi.
Le C n'est pas portable car ce n'est pas un langage déterministe.
Un programme strictement conforme (sans comportement indéfini) est déterministe. La portabilité en C est possible, elle n'est pas obligatoire.
Comme dans tout ce qui est mal défini.
N'importe quel l'angage d'assemblage est plus portable que le C car ils sont déterministes : toute implémentation suivant les spécifications donne les mêmes résultats. C'est ça la portabilité, pas ces pseudos-arguments de marchands de soupe qui veulent nous faire croire que c'est le plus populaire qui l'emporte.
Je le répète, cette portabilité existe en C.
Non, car il existe des comportements indéfinis. Portable veut dire : un programme calcule les mêmes choses pour toutes les entrées possibles pour toutes les implémentations conformes.
Le C n'est pas portable, inutile de faire croire le contraire en noyant le poisson.
-- Joe Cool
Contrairement à ce que l'on croit, la portabilité d'un langage est
uniquement déterminée par la qualité de sa spécification. Un
langage d'assemblage est portable car sa sémantique est univoque,
alors que la liste des « undefined behaviors » du C fait 20 pages.
Permettez-moi donc de traiter de con tout ceux qui affirment
péremptoirement que le C est portable.
Justement, les comportements indéfinis sont là pour faciliter la
portabilité du langage sur des architectures très différentes.
???
Vous rendez-vous compte de ce que vous dites ?
Oui et je maintiens. D'après le rationale, qui explique les intentions
de la norme du langage, les comportements indéfinis sont bien là pour
facilité les implémentations :
http://www.lysator.liu.se/c/rat/a.html#1-6
C'est alors un aveu d'incompétence de la part des rédacteurs de la
norme. Autant faire un langage entièrement composé de undefined
behavior, il sera d'autant plus portable et efficace.
Le résultat est que qu'il existe des compilateurs C pour presque tout
ce qui a un processeur, ce qui est loin d'être le cas pour les autres
langages.
La belle affaire : le C est le langage soutenu majoritairement par
l'industrie, qui seule à le pouvoir d'implémenter un mauvais langage sur
toutes les architectures. Ce n'est pas parce que tout le monde fait une
chose que ce n'est pas une mauvaise chose.
L'existence d'un compilateur sur chaque machine existante ne rend pas un
langage plus portable, sinon tout est portable : il suffit d'en faire un
compilateur.
Il y a un problème de faisabilité. Les comportements indéfinis sont là
pour rendre le portage faisable. Par exemple Java n'a aucun comportement
indéfini mais existe sur très peu d'architectures, et n'existera jamais
pour MS-DOS, par exemple.
Ce n'est qu'une question de politique. Un langage portable est un
langage qui ne contient aucun comportement indéfini. Sinon je peux
décider d'appeler « assemblage » l'ensemble des langages d'assemblage,
prétendre qu'ils sont tous identiques, à quelques comportement indéfinis
près, puis faire croire que ça rend « assemblage » portable, efficace,
simple, sûr, etc.
C'est n'importe quoi.
Le C n'est pas portable car ce n'est pas un langage déterministe.
Un programme strictement conforme (sans comportement indéfini) est
déterministe. La portabilité en C est possible, elle n'est pas obligatoire.
Comme dans tout ce qui est mal défini.
N'importe quel l'angage d'assemblage est plus portable que le C car ils
sont déterministes : toute implémentation suivant les spécifications
donne les mêmes résultats. C'est ça la portabilité, pas ces
pseudos-arguments de marchands de soupe qui veulent nous faire croire
que c'est le plus populaire qui l'emporte.
Je le répète, cette portabilité existe en C.
Non, car il existe des comportements indéfinis. Portable veut dire : un
programme calcule les mêmes choses pour toutes les entrées possibles
pour toutes les implémentations conformes.
Le C n'est pas portable, inutile de faire croire le contraire en noyant
le poisson.
Contrairement à ce que l'on croit, la portabilité d'un langage est uniquement déterminée par la qualité de sa spécification. Un langage d'assemblage est portable car sa sémantique est univoque, alors que la liste des « undefined behaviors » du C fait 20 pages.
Permettez-moi donc de traiter de con tout ceux qui affirment péremptoirement que le C est portable.
Justement, les comportements indéfinis sont là pour faciliter la portabilité du langage sur des architectures très différentes.
???
Vous rendez-vous compte de ce que vous dites ?
Oui et je maintiens. D'après le rationale, qui explique les intentions de la norme du langage, les comportements indéfinis sont bien là pour facilité les implémentations :
http://www.lysator.liu.se/c/rat/a.html#1-6
C'est alors un aveu d'incompétence de la part des rédacteurs de la norme. Autant faire un langage entièrement composé de undefined behavior, il sera d'autant plus portable et efficace.
Le résultat est que qu'il existe des compilateurs C pour presque tout ce qui a un processeur, ce qui est loin d'être le cas pour les autres langages.
La belle affaire : le C est le langage soutenu majoritairement par l'industrie, qui seule à le pouvoir d'implémenter un mauvais langage sur toutes les architectures. Ce n'est pas parce que tout le monde fait une chose que ce n'est pas une mauvaise chose.
L'existence d'un compilateur sur chaque machine existante ne rend pas un langage plus portable, sinon tout est portable : il suffit d'en faire un compilateur.
Il y a un problème de faisabilité. Les comportements indéfinis sont là pour rendre le portage faisable. Par exemple Java n'a aucun comportement indéfini mais existe sur très peu d'architectures, et n'existera jamais pour MS-DOS, par exemple.
Ce n'est qu'une question de politique. Un langage portable est un langage qui ne contient aucun comportement indéfini. Sinon je peux décider d'appeler « assemblage » l'ensemble des langages d'assemblage, prétendre qu'ils sont tous identiques, à quelques comportement indéfinis près, puis faire croire que ça rend « assemblage » portable, efficace, simple, sûr, etc.
C'est n'importe quoi.
Le C n'est pas portable car ce n'est pas un langage déterministe.
Un programme strictement conforme (sans comportement indéfini) est déterministe. La portabilité en C est possible, elle n'est pas obligatoire.
Comme dans tout ce qui est mal défini.
N'importe quel l'angage d'assemblage est plus portable que le C car ils sont déterministes : toute implémentation suivant les spécifications donne les mêmes résultats. C'est ça la portabilité, pas ces pseudos-arguments de marchands de soupe qui veulent nous faire croire que c'est le plus populaire qui l'emporte.
Je le répète, cette portabilité existe en C.
Non, car il existe des comportements indéfinis. Portable veut dire : un programme calcule les mêmes choses pour toutes les entrées possibles pour toutes les implémentations conformes.
Le C n'est pas portable, inutile de faire croire le contraire en noyant le poisson.
-- Joe Cool
Joe Cool
On 2005-03-09, Tom wrote:
Le C n'est peut-être pas parfait, évidemment, mais on peut _tout_ faire avec, y compris des erreurs, mais c'est le prix à payer je pense.
Prix bien trop cher. Si on veut faire quelque chose on le fait bien ou on ne le fait pas.
Ben on attend que toi pour nous sortir un OS en Caml ...
Parce que vous savez faire un OS en C vous. Montrez-nous le donc.
-- Joe Cool
On 2005-03-09, Tom <tom@tom.com> wrote:
Le C n'est peut-être pas parfait, évidemment, mais on peut _tout_ faire
avec, y compris des erreurs, mais c'est le prix à payer je pense.
Prix bien trop cher. Si on veut faire quelque chose on le fait bien ou
on ne le fait pas.
Ben on attend que toi pour nous sortir un OS en Caml ...
Parce que vous savez faire un OS en C vous. Montrez-nous le donc.
Le C n'est peut-être pas parfait, évidemment, mais on peut _tout_ faire avec, y compris des erreurs, mais c'est le prix à payer je pense.
Prix bien trop cher. Si on veut faire quelque chose on le fait bien ou on ne le fait pas.
Ben on attend que toi pour nous sortir un OS en Caml ...
Parce que vous savez faire un OS en C vous. Montrez-nous le donc.
-- Joe Cool
Emmanuel Florac
Le Tue, 08 Mar 2005 20:42:47 +0100, Joe Cool a écrit :
Permettez-moi donc de traiter de con tout ceux qui affirment péremptoirement que le C est portable.
Mince, c'est pour cela que tant de programmes en C comme Unix, gcc, les BSD utils, perl, TeX et des zillions d'autres existent sur tant de plateformes différentes, parce que C n'est pas portable?
-- In girum imus nocte ecce et consumimur igni
Le Tue, 08 Mar 2005 20:42:47 +0100, Joe Cool a écrit :
Permettez-moi donc de traiter de con tout ceux qui affirment
péremptoirement que le C est portable.
Mince, c'est pour cela que tant de programmes en C comme Unix, gcc, les
BSD utils, perl, TeX et des zillions d'autres existent sur tant de
plateformes différentes, parce que C n'est pas portable?
Le Tue, 08 Mar 2005 20:42:47 +0100, Joe Cool a écrit :
Permettez-moi donc de traiter de con tout ceux qui affirment péremptoirement que le C est portable.
Mince, c'est pour cela que tant de programmes en C comme Unix, gcc, les BSD utils, perl, TeX et des zillions d'autres existent sur tant de plateformes différentes, parce que C n'est pas portable?
-- In girum imus nocte ecce et consumimur igni
Joe Cool
Le C n'est pas portable car ce n'est pas un langage déterministe. N'importe quel l'angage d'assemblage est plus portable que le C
Un langage d'assemblage est par définition totalement lié à une architecture matérielle donnée. Il est donc rigoureusement non portable, à part quelques exception (genre compatibilité 8080/Z80, 80x86, ou émulation genre M68k sur PowerPC ou FX!32 sur Alpha/NT).
C'est complètement faux. Un langage d'assemblage est un langage comme un autre, indépendamment de la machine pour laquelle on a décidé arbitrairement de le réserver. Si les grands patrons de l'industrie informatique décidaient que l'assembleur sparc est portable, ils feraient des compilateurs sparc sur toutes les machines à la mode et tout le monde répeterait en coeur « sparc est portable ».
-- Joe Cool
Le C n'est pas portable car ce n'est pas un langage déterministe.
N'importe quel l'angage d'assemblage est plus portable que le C
Un langage d'assemblage est par définition totalement lié à une
architecture matérielle donnée. Il est donc rigoureusement non portable,
à part quelques exception (genre compatibilité 8080/Z80, 80x86, ou
émulation genre M68k sur PowerPC ou FX!32 sur Alpha/NT).
C'est complètement faux. Un langage d'assemblage est un langage comme un
autre, indépendamment de la machine pour laquelle on a décidé
arbitrairement de le réserver. Si les grands patrons de l'industrie
informatique décidaient que l'assembleur sparc est portable, ils
feraient des compilateurs sparc sur toutes les machines à la mode et
tout le monde répeterait en coeur « sparc est portable ».
Le C n'est pas portable car ce n'est pas un langage déterministe. N'importe quel l'angage d'assemblage est plus portable que le C
Un langage d'assemblage est par définition totalement lié à une architecture matérielle donnée. Il est donc rigoureusement non portable, à part quelques exception (genre compatibilité 8080/Z80, 80x86, ou émulation genre M68k sur PowerPC ou FX!32 sur Alpha/NT).
C'est complètement faux. Un langage d'assemblage est un langage comme un autre, indépendamment de la machine pour laquelle on a décidé arbitrairement de le réserver. Si les grands patrons de l'industrie informatique décidaient que l'assembleur sparc est portable, ils feraient des compilateurs sparc sur toutes les machines à la mode et tout le monde répeterait en coeur « sparc est portable ».
-- Joe Cool
Blaise Potard
Joe Cool wrote:
Bof, à une fusée Ariane pour chaque essai, à combien peut s'élever le déboguage d'un programme de contrôle en C ?
C'est marrant que tu dises ça, la première fusée ariane 5 avait justement explosé à cause d'un bout de programme ADA pourri, qui avait déclenché une exception non rattrapée (un dépassement de capacité dans le capteur d'accélération horizontale, prévu pour ariane 4, si mes souvenirs sont bons), qui a fait pété tout le système. Si le bout de programme en question avait été écrit en C, cela n'aurait probablement strictement rien provoqué...
Joe Cool wrote:
Bof, à une fusée Ariane pour chaque essai, à combien peut s'élever le
déboguage d'un programme de contrôle en C ?
C'est marrant que tu dises ça, la première fusée ariane 5 avait
justement explosé à cause d'un bout de programme ADA pourri, qui avait
déclenché une exception non rattrapée (un dépassement de capacité dans
le capteur d'accélération horizontale, prévu pour ariane 4, si mes
souvenirs sont bons), qui a fait pété tout le système. Si le bout de
programme en question avait été écrit en C, cela n'aurait probablement
strictement rien provoqué...
Bof, à une fusée Ariane pour chaque essai, à combien peut s'élever le déboguage d'un programme de contrôle en C ?
C'est marrant que tu dises ça, la première fusée ariane 5 avait justement explosé à cause d'un bout de programme ADA pourri, qui avait déclenché une exception non rattrapée (un dépassement de capacité dans le capteur d'accélération horizontale, prévu pour ariane 4, si mes souvenirs sont bons), qui a fait pété tout le système. Si le bout de programme en question avait été écrit en C, cela n'aurait probablement strictement rien provoqué...
Emmanuel Florac
Le Wed, 09 Mar 2005 09:19:17 +0100, Joe Cool a écrit :
Le C n'est pas portable car ce n'est pas un langage déterministe. N'importe quel l'angage d'assemblage est plus portable que le C
Un langage d'assemblage est par définition totalement lié à une architecture matérielle donnée. Il est donc rigoureusement non portable, à part quelques exception (genre compatibilité 8080/Z80, 80x86, ou émulation genre M68k sur PowerPC ou FX!32 sur Alpha/NT).
-- Dix grammes d'abstraction valent des tonnes de bricolage. Loi de Booker.
Le Wed, 09 Mar 2005 09:19:17 +0100, Joe Cool a écrit :
Le C n'est pas portable car ce n'est pas un langage déterministe.
N'importe quel l'angage d'assemblage est plus portable que le C
Un langage d'assemblage est par définition totalement lié à une
architecture matérielle donnée. Il est donc rigoureusement non portable,
à part quelques exception (genre compatibilité 8080/Z80, 80x86, ou
émulation genre M68k sur PowerPC ou FX!32 sur Alpha/NT).
--
Dix grammes d'abstraction valent des tonnes de bricolage.
Loi de Booker.
Le Wed, 09 Mar 2005 09:19:17 +0100, Joe Cool a écrit :
Le C n'est pas portable car ce n'est pas un langage déterministe. N'importe quel l'angage d'assemblage est plus portable que le C
Un langage d'assemblage est par définition totalement lié à une architecture matérielle donnée. Il est donc rigoureusement non portable, à part quelques exception (genre compatibilité 8080/Z80, 80x86, ou émulation genre M68k sur PowerPC ou FX!32 sur Alpha/NT).
-- Dix grammes d'abstraction valent des tonnes de bricolage. Loi de Booker.
Emmanuel Florac
Le Wed, 09 Mar 2005 09:47:21 +0100, Tom a écrit :
T'as pas compris encore ? Le C c'est l'apogée de l'informatique !
Quel naze, tout le monde sait que l'apogée de l'informatique, c'est Windev.
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
Le Wed, 09 Mar 2005 09:47:21 +0100, Tom a écrit :
T'as pas compris encore ? Le C c'est l'apogée de l'informatique !
Quel naze, tout le monde sait que l'apogée de l'informatique, c'est
Windev.
--
Mais monsieur, voudriez-vous que je me l'écorchasse?
Barbey d'Aurevilly.
