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.
C'est bizarre, je peux mettre un entier dans du vide, elle n'est donc pas vide, bizarre... Je pourrais mettre ce que je veux dans ce void, il est donc tout ce que je veux, alors que le vide est sensé n'être rien.
Je ne vois pas ce qui est bizarre de mettre quelquechose dans du vide, c'est beaucoup plus facile que dans du plein.
#include <stdlib.h>
int main(int argc, char **argv) { int a[10];
a[11] = 3; return EXIT_SUCCESS; }
Ça compile sans un mot : le C me permet donc explicitement de programmer des choses qui ne sont pas des programmes.
Ça s'exécute sans un mot : c'est donc un programme alors ?
J'ai un compilateur qui produit : Runtime error: dereferencing invalid pointer
un autre : Erreur de segmentation
Ce n'est pas ce que j'appelle sans un mot.
Qu'est-il donc sensé faire dans cette case qui n'existe pas mais dans laquelle on peut écrire ? Serait-ce une case void ?
Il produit une erreur. Que devrait-il faire d'autre ?
Et bien ce n'est rien que des mensonges. Un programmeur se plante souvent et n'a aucun moyen de savoir ou et quand il se plante dans le cas général.
Et ceci quelque soit le langage. La seule manière d'éviter un maximum d'erreur est de tester abondamment.
Quand la sûreté du programme repose uniquement sur le programmeur, la probabilité d'avoir une erreur non détectée augment exponentiellement avec la quantité de code.
Le taux est proportionnel à la taille du code et non exponentielle. Et cela dépend plus du programmeur que du langage.
C'est bizarre, je peux mettre un entier dans du vide, elle n'est donc
pas vide, bizarre... Je pourrais mettre ce que je veux dans ce void, il
est donc tout ce que je veux, alors que le vide est sensé n'être rien.
Je ne vois pas ce qui est bizarre de mettre quelquechose dans du vide,
c'est beaucoup plus facile que dans du plein.
#include <stdlib.h>
int main(int argc, char **argv)
{
int a[10];
a[11] = 3;
return EXIT_SUCCESS;
}
Ça compile sans un mot : le C me permet donc explicitement de programmer
des choses qui ne sont pas des programmes.
Ça s'exécute sans un mot : c'est donc un programme alors ?
J'ai un compilateur qui produit :
Runtime error: dereferencing invalid pointer
un autre :
Erreur de segmentation
Ce n'est pas ce que j'appelle sans un mot.
Qu'est-il
donc sensé faire dans cette case qui n'existe pas mais dans laquelle on
peut écrire ? Serait-ce une case void ?
Il produit une erreur. Que devrait-il faire d'autre ?
Et bien ce n'est rien que des mensonges. Un programmeur se plante
souvent et n'a aucun moyen de savoir ou et quand il se plante dans le
cas général.
Et ceci quelque soit le langage. La seule manière d'éviter un maximum
d'erreur est de tester abondamment.
Quand la sûreté du programme repose uniquement sur le programmeur, la
probabilité d'avoir une erreur non détectée augment exponentiellement
avec la quantité de code.
Le taux est proportionnel à la taille du code et non exponentielle. Et
cela dépend plus du programmeur que du langage.
C'est bizarre, je peux mettre un entier dans du vide, elle n'est donc pas vide, bizarre... Je pourrais mettre ce que je veux dans ce void, il est donc tout ce que je veux, alors que le vide est sensé n'être rien.
Je ne vois pas ce qui est bizarre de mettre quelquechose dans du vide, c'est beaucoup plus facile que dans du plein.
#include <stdlib.h>
int main(int argc, char **argv) { int a[10];
a[11] = 3; return EXIT_SUCCESS; }
Ça compile sans un mot : le C me permet donc explicitement de programmer des choses qui ne sont pas des programmes.
Ça s'exécute sans un mot : c'est donc un programme alors ?
J'ai un compilateur qui produit : Runtime error: dereferencing invalid pointer
un autre : Erreur de segmentation
Ce n'est pas ce que j'appelle sans un mot.
Qu'est-il donc sensé faire dans cette case qui n'existe pas mais dans laquelle on peut écrire ? Serait-ce une case void ?
Il produit une erreur. Que devrait-il faire d'autre ?
Et bien ce n'est rien que des mensonges. Un programmeur se plante souvent et n'a aucun moyen de savoir ou et quand il se plante dans le cas général.
Et ceci quelque soit le langage. La seule manière d'éviter un maximum d'erreur est de tester abondamment.
Quand la sûreté du programme repose uniquement sur le programmeur, la probabilité d'avoir une erreur non détectée augment exponentiellement avec la quantité de code.
Le taux est proportionnel à la taille du code et non exponentielle. Et cela dépend plus du programmeur que du langage.
-- Richard
nicolas vigier
On 2005-03-08, Joe Cool wrote:
Voilà une sémantique d'une précison toute littéraire.
void f(int a) {} ne retourne aucune donnée, ce qui semble signifier que void est le (hum) type qui représente le vide : ça tombe bien « void » veut dire « vide » en anglais.
C'est bizarre, je peux mettre un entier dans du vide, elle n'est donc pas vide, bizarre... Je pourrais mettre ce que je veux dans ce void, il est donc tout ce que je veux, alors que le vide est sensé n'être rien.
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.
int main(int argc, char **argv) { void a;
(int)a = 3; return (int)a; }
Voilà maitenant que ça ne compile plus ! Alors ce void, c'est out ou c'est rien ? C'est surtout n'importe quoi.
Faut vraiment etre un cretin pour pas comprendre la signification du void en C. Oui, c'est pas forcement evident juste en regardant le nom, mais tu prend un livre de C, tu regardes quelques exemples de code, et si t'arrives pas a comprendre c'est que la programmation, quel que soit le langage, c'est pas pour toi.
On 2005-03-08, Joe Cool <zierouhli_@d_free.fr> wrote:
Voilà une sémantique d'une précison toute littéraire.
void f(int a) {} ne retourne aucune donnée, ce qui semble signifier que
void est le (hum) type qui représente le vide : ça tombe bien « void »
veut dire « vide » en anglais.
C'est bizarre, je peux mettre un entier dans du vide, elle n'est donc
pas vide, bizarre... Je pourrais mettre ce que je veux dans ce void, il
est donc tout ce que je veux, alors que le vide est sensé n'être rien.
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.
int main(int argc, char **argv)
{
void a;
(int)a = 3;
return (int)a;
}
Voilà maitenant que ça ne compile plus ! Alors ce void, c'est out ou
c'est rien ? C'est surtout n'importe quoi.
Faut vraiment etre un cretin pour pas comprendre la signification du
void en C. Oui, c'est pas forcement evident juste en regardant le nom,
mais tu prend un livre de C, tu regardes quelques exemples de code, et
si t'arrives pas a comprendre c'est que la programmation, quel que soit
le langage, c'est pas pour toi.
Voilà une sémantique d'une précison toute littéraire.
void f(int a) {} ne retourne aucune donnée, ce qui semble signifier que void est le (hum) type qui représente le vide : ça tombe bien « void » veut dire « vide » en anglais.
C'est bizarre, je peux mettre un entier dans du vide, elle n'est donc pas vide, bizarre... Je pourrais mettre ce que je veux dans ce void, il est donc tout ce que je veux, alors que le vide est sensé n'être rien.
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.
int main(int argc, char **argv) { void a;
(int)a = 3; return (int)a; }
Voilà maitenant que ça ne compile plus ! Alors ce void, c'est out ou c'est rien ? C'est surtout n'importe quoi.
Faut vraiment etre un cretin pour pas comprendre la signification du void en C. Oui, c'est pas forcement evident juste en regardant le nom, mais tu prend un livre de C, tu regardes quelques exemples de code, et si t'arrives pas a comprendre c'est que la programmation, quel que soit le langage, c'est pas pour toi.
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 ?
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.
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.
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 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.
-- 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 ?
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.
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.
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 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.
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 ?
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.
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.
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 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.
-- Joe Cool
Tom
Tu parles du noyau Linux ? Il n'est pas en C. Il est écrit dans un langage qui a une syntaxe qui ressemble considérablement à celle du C, et certains bouts du code sont du code C valide, mais ce n'est pas, stricto sensu, du C.
Rien que le JAVA c'est du C déguisé. Le C++ c'est du C. Toutes ces merdes impératives ne sont que le même langage. On change un truc à droite, un à gauche, on fait des librairies toutes neuves, on change la couleur de la couverture des bouquins et hop on pense avoir un nouveau langage.
La philosophie du C est dépassée depuis vingt à trente ans.
Tom
Tu parles du noyau Linux ? Il n'est pas en C. Il est écrit dans un langage
qui a une syntaxe qui ressemble considérablement à celle du C, et certains
bouts du code sont du code C valide, mais ce n'est pas, stricto sensu, du C.
Rien que le JAVA c'est du C déguisé. Le C++ c'est du C. Toutes ces
merdes impératives ne sont que le même langage. On change un truc à
droite, un à gauche, on fait des librairies toutes neuves, on change la
couleur de la couverture des bouquins et hop on pense avoir un nouveau
langage.
La philosophie du C est dépassée depuis vingt à trente ans.
Tu parles du noyau Linux ? Il n'est pas en C. Il est écrit dans un langage qui a une syntaxe qui ressemble considérablement à celle du C, et certains bouts du code sont du code C valide, mais ce n'est pas, stricto sensu, du C.
Rien que le JAVA c'est du C déguisé. Le C++ c'est du C. Toutes ces merdes impératives ne sont que le même langage. On change un truc à droite, un à gauche, on fait des librairies toutes neuves, on change la couleur de la couverture des bouquins et hop on pense avoir un nouveau langage.
La philosophie du C est dépassée depuis vingt à trente ans.
Tom
Joe Cool
( Tue, 08 Mar 2005 22:52:18 +0000 ) Guillaume L. :
tu es certain que c'est le compilateur qui hurlait ?
certain, non. j'ai fait mon script, j'ai demandé de l'éxécuter, et "stack overflow". qui a parlé? ... je sais pas exactement.
Quand un programme caml est interprété, la pile est limitée par défaut à 262144 mots. Quand il est compilé, c'est le système d'exploitation qui fixe la limite.
-- Joe Cool
( Tue, 08 Mar 2005 22:52:18 +0000 ) Guillaume L. :
tu es certain que c'est le compilateur qui hurlait ?
certain, non. j'ai fait mon script, j'ai demandé de l'éxécuter, et
"stack overflow". qui a parlé? ... je sais pas exactement.
Quand un programme caml est interprété, la pile est limitée par défaut à
262144 mots. Quand il est compilé, c'est le système d'exploitation qui
fixe la limite.
( Tue, 08 Mar 2005 22:52:18 +0000 ) Guillaume L. :
tu es certain que c'est le compilateur qui hurlait ?
certain, non. j'ai fait mon script, j'ai demandé de l'éxécuter, et "stack overflow". qui a parlé? ... je sais pas exactement.
Quand un programme caml est interprété, la pile est limitée par défaut à 262144 mots. Quand il est compilé, c'est le système d'exploitation qui fixe la limite.
-- Joe Cool
Tom
Où est le problème ? Tant qu'on s'assure de ne jamais dépasser l'intervalle de validité des entiers, ce sont bien les mêmes entiers, il n'y a aucun problème. Et comme justement la transition va dans le sens d'un élargissement des valeurs, il n'y a pas de problème.
Pour moi la définition d'un entier c'est 0 | Successeur d'un autre entier. Un sous ensemble des entiers ne peut pas représenter les entiers. C'est un comble de changer la taille de l'intervalle d'une machine à l'autre.
Tom
Où est le problème ? Tant qu'on s'assure de ne jamais dépasser l'intervalle
de validité des entiers, ce sont bien les mêmes entiers, il n'y a aucun
problème. Et comme justement la transition va dans le sens d'un
élargissement des valeurs, il n'y a pas de problème.
Pour moi la définition d'un entier c'est 0 | Successeur d'un autre entier.
Un sous ensemble des entiers ne peut pas représenter les entiers. C'est
un comble de changer la taille de l'intervalle d'une machine à l'autre.
Où est le problème ? Tant qu'on s'assure de ne jamais dépasser l'intervalle de validité des entiers, ce sont bien les mêmes entiers, il n'y a aucun problème. Et comme justement la transition va dans le sens d'un élargissement des valeurs, il n'y a pas de problème.
Pour moi la définition d'un entier c'est 0 | Successeur d'un autre entier. Un sous ensemble des entiers ne peut pas représenter les entiers. C'est un comble de changer la taille de l'intervalle d'une machine à l'autre.
Tom
Joe Cool
Quand la sûreté du programme repose uniquement sur le programmeur, la probabilité d'avoir une erreur non détectée augment exponentiellement avec la quantité de code.
Le taux est proportionnel à la taille du code et non exponentielle. Et cela dépend plus du programmeur que du langage.
Encore ce mythe du programmeur parfait.
Comment faire comprendre à ces gens qu'ils ne sont pas le splus beaux, lmes plus forts, les meilleurs et que si ils ne s'en rendent pas compte assez vite, ils vont droit dans le mur.
-- Joe Cool
Quand la sûreté du programme repose uniquement sur le programmeur, la
probabilité d'avoir une erreur non détectée augment exponentiellement
avec la quantité de code.
Le taux est proportionnel à la taille du code et non exponentielle. Et
cela dépend plus du programmeur que du langage.
Encore ce mythe du programmeur parfait.
Comment faire comprendre à ces gens qu'ils ne sont pas le splus beaux,
lmes plus forts, les meilleurs et que si ils ne s'en rendent pas compte
assez vite, ils vont droit dans le mur.
Quand la sûreté du programme repose uniquement sur le programmeur, la probabilité d'avoir une erreur non détectée augment exponentiellement avec la quantité de code.
Le taux est proportionnel à la taille du code et non exponentielle. Et cela dépend plus du programmeur que du langage.
Encore ce mythe du programmeur parfait.
Comment faire comprendre à ces gens qu'ils ne sont pas le splus beaux, lmes plus forts, les meilleurs et que si ils ne s'en rendent pas compte assez vite, ils vont droit dans le mur.
-- Joe Cool
Joe Cool
Je crois que tu viens de trouver sans t'en rendre compte l'élément essentiel pour lequel ton troll s'effrondre. Quelque soit le langage (même un programme Ada peut faire exploser une fusée Ariane), il existe deux types de développeurs: le bon développeur qui sait développer et le mauvais développeur. Le bon ressemble au mauvais sauf qu'il est bon ! Bref, tu devrais regarder entre la chaise et le clavier et tu auras 90% des causes de problèmes informatiques.
C'est pourquoi il faut que le langage prenne sur lui toutes les erreurs du programmeur et les corrige malgré lui, car tout programmeur - sans exception - fait des erreurs. Programmer des ressources critiques avec des langages qui ne certifient pas la qualité de leur code est stupide et criminel.
Programmer en C est stupide et criminel.
-- Joe Cool
Je crois que tu viens de trouver sans t'en rendre compte l'élément
essentiel pour lequel ton troll s'effrondre. Quelque soit le langage
(même un programme Ada peut faire exploser une fusée Ariane), il existe
deux types de développeurs: le bon développeur qui sait développer et le
mauvais développeur. Le bon ressemble au mauvais sauf qu'il est bon !
Bref, tu devrais regarder entre la chaise et le clavier et tu auras 90%
des causes de problèmes informatiques.
C'est pourquoi il faut que le langage prenne sur lui toutes les erreurs
du programmeur et les corrige malgré lui, car tout programmeur - sans
exception - fait des erreurs. Programmer des ressources critiques avec
des langages qui ne certifient pas la qualité de leur code est stupide
et criminel.
Je crois que tu viens de trouver sans t'en rendre compte l'élément essentiel pour lequel ton troll s'effrondre. Quelque soit le langage (même un programme Ada peut faire exploser une fusée Ariane), il existe deux types de développeurs: le bon développeur qui sait développer et le mauvais développeur. Le bon ressemble au mauvais sauf qu'il est bon ! Bref, tu devrais regarder entre la chaise et le clavier et tu auras 90% des causes de problèmes informatiques.
C'est pourquoi il faut que le langage prenne sur lui toutes les erreurs du programmeur et les corrige malgré lui, car tout programmeur - sans exception - fait des erreurs. Programmer des ressources critiques avec des langages qui ne certifient pas la qualité de leur code est stupide et criminel.
Programmer en C est stupide et criminel.
-- Joe Cool
Tom
Alors si on veux pinailler, je n'ai _jamais_ vu un seul bout de code écrit en C qui ne comporte pas à un endroit ou un autre un truc qui n'est pas implementation defined. Et je ne parle pas de trucs pathologiques du style i+=i++ !
Un exemple flagrant de la faiblesse du C : ce i+=i++ n'est pas un comportement défini. Certains compilateurs vont incrémenter avant, d'autres après l'affectation. Quel exemple de portabilité ! :-)
Dommage. J'avais écrit un code de division de polynôme dans GF(2**256) pour faire du décodage souple de codes en blocs. Le truc est sur mon PS/2 à 500 km d'ici et compilé avec Borland C sous IBM DOS 5.00. Note bien : code écrit par moi. J'ai passé des jours à le compiler sur une Sun tournant sous Solaris 2.5 (gcc 2.7.2.1), parce que tous les calculs se faisaient en utilisant les bits des entiers à grands coups de décalages. Et comme la taille de ces trucs change, il y a des tas de données qui passaient à l'as et mes matrices étaient nulles par bloc ! Un C parfaitement à la norme peut ne pas être portable.
Peut-il être portable ? Ah ouais j'oubliais : il faut mettre trois kilomètres de #ifdef, #define et compagnie. Que c'est joliiiiiiiii !
Tom
Alors si on veux pinailler, je n'ai _jamais_ vu un seul bout de code
écrit en C qui ne comporte pas à un endroit ou un autre un truc qui
n'est pas implementation defined. Et je ne parle pas de trucs
pathologiques du style i+=i++ !
Un exemple flagrant de la faiblesse du C : ce i+=i++ n'est pas un
comportement défini. Certains compilateurs vont incrémenter avant,
d'autres après l'affectation. Quel exemple de portabilité ! :-)
Dommage. J'avais écrit un code de division de polynôme dans
GF(2**256) pour faire du décodage souple de codes en blocs. Le truc
est sur mon PS/2 à 500 km d'ici et compilé avec Borland C sous IBM
DOS 5.00. Note bien : code écrit par moi. J'ai passé des jours à le
compiler sur une Sun tournant sous Solaris 2.5 (gcc 2.7.2.1), parce
que tous les calculs se faisaient en utilisant les bits des entiers
à grands coups de décalages. Et comme la taille de ces trucs change,
il y a des tas de données qui passaient à l'as et mes matrices
étaient nulles par bloc ! Un C parfaitement à la norme peut ne pas
être portable.
Peut-il être portable ?
Ah ouais j'oubliais : il faut mettre trois kilomètres de #ifdef, #define
et compagnie. Que c'est joliiiiiiiii !
Alors si on veux pinailler, je n'ai _jamais_ vu un seul bout de code écrit en C qui ne comporte pas à un endroit ou un autre un truc qui n'est pas implementation defined. Et je ne parle pas de trucs pathologiques du style i+=i++ !
Un exemple flagrant de la faiblesse du C : ce i+=i++ n'est pas un comportement défini. Certains compilateurs vont incrémenter avant, d'autres après l'affectation. Quel exemple de portabilité ! :-)
Dommage. J'avais écrit un code de division de polynôme dans GF(2**256) pour faire du décodage souple de codes en blocs. Le truc est sur mon PS/2 à 500 km d'ici et compilé avec Borland C sous IBM DOS 5.00. Note bien : code écrit par moi. J'ai passé des jours à le compiler sur une Sun tournant sous Solaris 2.5 (gcc 2.7.2.1), parce que tous les calculs se faisaient en utilisant les bits des entiers à grands coups de décalages. Et comme la taille de ces trucs change, il y a des tas de données qui passaient à l'as et mes matrices étaient nulles par bloc ! Un C parfaitement à la norme peut ne pas être portable.
Peut-il être portable ? Ah ouais j'oubliais : il faut mettre trois kilomètres de #ifdef, #define et compagnie. Que c'est joliiiiiiiii !
Tom
Tom
Et je peux t'assurer que je m'efforce de suivre scrupuleusement la norme ...
C'est ça le problème en C : il faut s'efforcer de respecter la norme. Ce qui veut dire qu'il faut le vouloir de respecter la norme. Ca veut dire quoi ça ? Que l'on peut faire des programmes ne respectant pas les normes ? Donc que les compilateurs ne les respectent pas ou n'arrivent pas à forcer le programmeur à les respecter. Il y a forcément un problème quelque part avant même que le programmeur ne tape une ligne de code.
Tom
Et je peux t'assurer que je m'efforce de suivre scrupuleusement la norme ...
C'est ça le problème en C : il faut s'efforcer de respecter la norme. Ce
qui veut dire qu'il faut le vouloir de respecter la norme. Ca veut dire
quoi ça ? Que l'on peut faire des programmes ne respectant pas les
normes ? Donc que les compilateurs ne les respectent pas ou n'arrivent
pas à forcer le programmeur à les respecter. Il y a forcément un
problème quelque part avant même que le programmeur ne tape une ligne de
code.
Et je peux t'assurer que je m'efforce de suivre scrupuleusement la norme ...
C'est ça le problème en C : il faut s'efforcer de respecter la norme. Ce qui veut dire qu'il faut le vouloir de respecter la norme. Ca veut dire quoi ça ? Que l'on peut faire des programmes ne respectant pas les normes ? Donc que les compilateurs ne les respectent pas ou n'arrivent pas à forcer le programmeur à les respecter. Il y a forcément un problème quelque part avant même que le programmeur ne tape une ligne de code.
