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.
On ne peut pas sérieusement programmer avec un langage bricolé à la va-vite il y a plus de 35 ans. Ceux qui affirment le contraire ne méritent pas le nom d'informaticien.
Ouais, en gros, "ceux qui ne sont pas d'accord avec moi sont forcement des cons" ?
On 2005-03-08, Joe Cool <zierouhli_@d_free.fr> wrote:
On ne peut pas sérieusement programmer avec un langage bricolé à la
va-vite il y a plus de 35 ans. Ceux qui affirment le contraire ne
méritent pas le nom d'informaticien.
Ouais, en gros, "ceux qui ne sont pas d'accord avec moi sont forcement
des cons" ?
On ne peut pas sérieusement programmer avec un langage bricolé à la va-vite il y a plus de 35 ans. Ceux qui affirment le contraire ne méritent pas le nom d'informaticien.
Ouais, en gros, "ceux qui ne sont pas d'accord avec moi sont forcement des cons" ?
Le 08-03-2005, à propos de Re: a-t-on le choix ?, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Ah bon ? Dans ce cas, d'où provient un kernel panic ?
Tu parles du noyau Linux ? Il n'est pas en C.
C'est nouveau, ça. C + assembleur. Je mets le nez dedans depuis assez longtemps, et je n'ai encore jamais vu autre chose que du C. D'ailleurs, son compilo est gcc.
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.
Exemples. Et avec en prime le pourquoi du comment ce n'est pas du C valide.
Si le C est _bien_ écrit avec des typedef dans tous les sens pour définir des objets de taille et de structure connues !
Non. Un code qui dépend de la taille des objets de manière incontrôlée ne peut pas être du C valide.
?
Sous DOS (Borland C) : short = 16 bits int = 16 bits long = 32 bits
Sous Linux i386 (gcc) : short = 16 bits int = 32 bits long = 32 bits
Sous Linux alpha (gcc) : short = 16 bits int = 32 bits long = 64 bits
Sous sparc64, idem.
Maintenant, portez moi un code utilisant int et long de DOS à sparc64 pour rigoler ! Là, on commence à apprécier sérieusement les integer*8 (un peu hors norme) du Fortran ! Ça fait vingt ans que je code en C, et pour l'instant, je n'ai pas trouvé mieux et plus portable que des grands coups de typedef conditionnés par un script configure.
JKB
Le 08-03-2005, à propos de
Re: a-t-on le choix ?,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrnd2rr3l.mkg.knatschke@rayleigh.systella.fr>, a
écrit :
Ah bon ? Dans ce cas, d'où provient un kernel panic ?
Tu parles du noyau Linux ? Il n'est pas en C.
C'est nouveau, ça. C + assembleur. Je mets le nez dedans depuis
assez longtemps, et je n'ai encore jamais vu autre chose que du C.
D'ailleurs, son compilo est gcc.
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.
Exemples. Et avec en prime le pourquoi du comment ce n'est pas du C
valide.
Si le C est _bien_ écrit avec des typedef dans tous les sens pour
définir des objets de taille et de structure connues !
Non. Un code qui dépend de la taille des objets de manière incontrôlée ne
peut pas être du C valide.
?
Sous DOS (Borland C) :
short = 16 bits
int = 16 bits
long = 32 bits
Sous Linux i386 (gcc) :
short = 16 bits
int = 32 bits
long = 32 bits
Sous Linux alpha (gcc) :
short = 16 bits
int = 32 bits
long = 64 bits
Sous sparc64, idem.
Maintenant, portez moi un code utilisant int et long de DOS à
sparc64 pour rigoler ! Là, on commence à apprécier sérieusement les
integer*8 (un peu hors norme) du Fortran ! Ça fait vingt ans que je
code en C, et pour l'instant, je n'ai pas trouvé mieux et plus
portable que des grands coups de typedef conditionnés par un script
configure.
Le 08-03-2005, à propos de Re: a-t-on le choix ?, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Ah bon ? Dans ce cas, d'où provient un kernel panic ?
Tu parles du noyau Linux ? Il n'est pas en C.
C'est nouveau, ça. C + assembleur. Je mets le nez dedans depuis assez longtemps, et je n'ai encore jamais vu autre chose que du C. D'ailleurs, son compilo est gcc.
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.
Exemples. Et avec en prime le pourquoi du comment ce n'est pas du C valide.
Si le C est _bien_ écrit avec des typedef dans tous les sens pour définir des objets de taille et de structure connues !
Non. Un code qui dépend de la taille des objets de manière incontrôlée ne peut pas être du C valide.
?
Sous DOS (Borland C) : short = 16 bits int = 16 bits long = 32 bits
Sous Linux i386 (gcc) : short = 16 bits int = 32 bits long = 32 bits
Sous Linux alpha (gcc) : short = 16 bits int = 32 bits long = 64 bits
Sous sparc64, idem.
Maintenant, portez moi un code utilisant int et long de DOS à sparc64 pour rigoler ! Là, on commence à apprécier sérieusement les integer*8 (un peu hors norme) du Fortran ! Ça fait vingt ans que je code en C, et pour l'instant, je n'ai pas trouvé mieux et plus portable que des grands coups de typedef conditionnés par un script configure.
Exemples. Et avec en prime le pourquoi du comment ce n'est pas du C valide.
Je suis en train de pinailler sur ce qui est du C ou pas. Le noyau Linux, par exemple, est bourré de cas qui sont implementation defined ou undefined. Ça passe parce qu'on le compile avec un compilateur bien précis, qui fournit bien plus de garanties que ne le fait le C, mais stricto sensu ce n'est pas du C. Pour exactement la même raison que :
int a[10], b; a[10] = 42;
n'est pas du C.
Maintenant, portez moi un code utilisant int et long de DOS à sparc64 pour rigoler !
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.
Je peux dire autrement : qu'on me montre un code utilisant int et long de DOS qui ne marche pas sur sparc64, et je montrerai en quoi ce n'est pas du C.
JKB , dans le message <slrnd2rs7q.mkg.knatschke@rayleigh.systella.fr>, a
écrit :
Exemples. Et avec en prime le pourquoi du comment ce n'est pas du C
valide.
Je suis en train de pinailler sur ce qui est du C ou pas. Le noyau Linux,
par exemple, est bourré de cas qui sont implementation defined ou undefined.
Ça passe parce qu'on le compile avec un compilateur bien précis, qui fournit
bien plus de garanties que ne le fait le C, mais stricto sensu ce n'est pas
du C. Pour exactement la même raison que :
int a[10], b;
a[10] = 42;
n'est pas du C.
Maintenant, portez moi un code utilisant int et long de DOS à
sparc64 pour rigoler !
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.
Je peux dire autrement : qu'on me montre un code utilisant int et long de
DOS qui ne marche pas sur sparc64, et je montrerai en quoi ce n'est pas du
C.
Exemples. Et avec en prime le pourquoi du comment ce n'est pas du C valide.
Je suis en train de pinailler sur ce qui est du C ou pas. Le noyau Linux, par exemple, est bourré de cas qui sont implementation defined ou undefined. Ça passe parce qu'on le compile avec un compilateur bien précis, qui fournit bien plus de garanties que ne le fait le C, mais stricto sensu ce n'est pas du C. Pour exactement la même raison que :
int a[10], b; a[10] = 42;
n'est pas du C.
Maintenant, portez moi un code utilisant int et long de DOS à sparc64 pour rigoler !
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.
Je peux dire autrement : qu'on me montre un code utilisant int et long de DOS qui ne marche pas sur sparc64, et je montrerai en quoi ce n'est pas du C.
JustMe
Joe Cool a exposé le 08/03/2005 :
Un langage qui permet explicitement de faire planter une machine a forcément été conçu pour faire planter la machine.
Un langage qui interdirait de planter une machine ne permet pas la réalisation d'un systeme d'exploitation
Joe Cool a exposé le 08/03/2005 :
Un langage qui permet explicitement de faire planter une machine a forcément
été conçu pour faire planter la machine.
Un langage qui interdirait de planter une machine ne permet pas la
réalisation d'un systeme d'exploitation
Un langage qui permet explicitement de faire planter une machine a forcément été conçu pour faire planter la machine.
Un langage qui interdirait de planter une machine ne permet pas la réalisation d'un systeme d'exploitation
JKB
Le 08-03-2005, à propos de Re: a-t-on le choix ?, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Exemples. Et avec en prime le pourquoi du comment ce n'est pas du C valide.
Je suis en train de pinailler sur ce qui est du C ou pas. Le noyau Linux, par exemple, est bourré de cas qui sont implementation defined ou undefined. Ça passe parce qu'on le compile avec un compilateur bien précis, qui fournit bien plus de garanties que ne le fait le C, mais stricto sensu ce n'est pas du C. Pour exactement la même raison que :
int a[10], b; a[10] = 42;
n'est pas du C.
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++ !
Maintenant, portez moi un code utilisant int et long de DOS à sparc64 pour rigoler !
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.
Sauf que dès qu'on met ça dans un tableau, on a des surprises ! Parce que l'élément suivant n'est pas du tout où le compilo s'attend à le trouver. Par ailleurs, lorsqu'un code est écrit par plusieurs personnes, il y a toujours des casts malheureux qui ne dérange pas _sauf_ lorsqu'on change d'architecture où tout se casse la gueule (sjmea).
Je peux dire autrement : qu'on me montre un code utilisant int et long de DOS qui ne marche pas sur sparc64, et je montrerai en quoi ce n'est pas du C.
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.
JKB
Le 08-03-2005, à propos de
Re: a-t-on le choix ?,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrnd2rs7q.mkg.knatschke@rayleigh.systella.fr>, a
écrit :
Exemples. Et avec en prime le pourquoi du comment ce n'est pas du C
valide.
Je suis en train de pinailler sur ce qui est du C ou pas. Le noyau Linux,
par exemple, est bourré de cas qui sont implementation defined ou undefined.
Ça passe parce qu'on le compile avec un compilateur bien précis, qui fournit
bien plus de garanties que ne le fait le C, mais stricto sensu ce n'est pas
du C. Pour exactement la même raison que :
int a[10], b;
a[10] = 42;
n'est pas du C.
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++ !
Maintenant, portez moi un code utilisant int et long de DOS à
sparc64 pour rigoler !
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.
Sauf que dès qu'on met ça dans un tableau, on a des surprises !
Parce que l'élément suivant n'est pas du tout où le compilo s'attend
à le trouver. Par ailleurs, lorsqu'un code est écrit par plusieurs
personnes, il y a toujours des casts malheureux qui ne dérange pas
_sauf_ lorsqu'on change d'architecture où tout se casse la gueule
(sjmea).
Je peux dire autrement : qu'on me montre un code utilisant int et long de
DOS qui ne marche pas sur sparc64, et je montrerai en quoi ce n'est pas du
C.
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.
Le 08-03-2005, à propos de Re: a-t-on le choix ?, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Exemples. Et avec en prime le pourquoi du comment ce n'est pas du C valide.
Je suis en train de pinailler sur ce qui est du C ou pas. Le noyau Linux, par exemple, est bourré de cas qui sont implementation defined ou undefined. Ça passe parce qu'on le compile avec un compilateur bien précis, qui fournit bien plus de garanties que ne le fait le C, mais stricto sensu ce n'est pas du C. Pour exactement la même raison que :
int a[10], b; a[10] = 42;
n'est pas du C.
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++ !
Maintenant, portez moi un code utilisant int et long de DOS à sparc64 pour rigoler !
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.
Sauf que dès qu'on met ça dans un tableau, on a des surprises ! Parce que l'élément suivant n'est pas du tout où le compilo s'attend à le trouver. Par ailleurs, lorsqu'un code est écrit par plusieurs personnes, il y a toujours des casts malheureux qui ne dérange pas _sauf_ lorsqu'on change d'architecture où tout se casse la gueule (sjmea).
Je peux dire autrement : qu'on me montre un code utilisant int et long de DOS qui ne marche pas sur sparc64, et je montrerai en quoi ce n'est pas du C.
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.
JKB
Rakotomandimby (R12y) Mihamina
( Tue, 08 Mar 2005 19:13:29 +0000 ) JKB :
J'avais écrit un code de division de polynôme dans GF(2**256) pour faire du décodage souple de codes en blocs.
dites... vous pouvez pas faire des choses humaines :-) ? -- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
( Tue, 08 Mar 2005 19:13:29 +0000 ) JKB :
J'avais écrit un code de division de polynôme dans
GF(2**256) pour faire du décodage souple de codes en blocs.
dites... vous pouvez pas faire des choses humaines :-) ?
--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
J'avais écrit un code de division de polynôme dans GF(2**256) pour faire du décodage souple de codes en blocs.
dites... vous pouvez pas faire des choses humaines :-) ? -- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
Joe Cool
Regardez les codes sources d'un programme en C. Même le code d'un bon programmeur n'est rempli que d'horreurs.
C'est faux.
Nan !
Ce fameux "void" : c'est quoi cette abomination de la programmation ? Il n'y a aucune sémantique valable là derrière.
Si : il correspond à une tournure impérative et pas interrogative, il a à peu près autant de sens qu'un point d'exclamation par rapport à un point d'interrogation.
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.
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.
Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de 10 éléments.
On ne peut pas, tu te trompes.
#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 ? Qu'est-il donc sensé faire dans cette case qui n'existe pas mais dans laquelle on peut écrire ? Serait-ce une case void ?
Ce langage surestime beaucoup les capacités des personnes qui vont l'utiliser.
Quand c'est toi qui l'écris, probablement, en effet. Quand c'est moi, ce n'est pas le cas.
Le C est un langage démagogique qui a du succès car il fait croire au programmeur qu'il est le meilleur, qu'il est parfait et qu'il ne fait jamais d'erreur. Un véritable informaticien sait qu'un système, quel qu'il soit, machine ou programmeur, n'a aucun moyen de savoir si il est erroné. Si il le croit, c'est qu'il est incohérent, car seul un être incohérent peut se croire sans défaut.
En C : tant pis c'est perdu. Un trou de mémoire ?
Tous les programmeurs ne sont pas aussi laxistes, loin de là.
Bien sûr, c'est toujours le programmeur qui est en tort. Le langage n'y est pour rien : un bon programmeur programme bien quel que soit le langage.
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.
Dès que les programmes ont commencé à ne plus rentrer sur une disquette ils sont devenus beaucoup trop compliqués pour fonctionner correctement.
C'est parfaitement faux. Au contraire, les contraintes de taille plus faibles permettent une programmation plus modulaire et plus claire, donc des programmes plus simples qui font pourtant plus de choses.
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.
Vous avez beau vous croire parfait, vous n'échappez pas à la règle.
-- Joe Cool
Regardez les codes sources d'un programme en C. Même le code d'un
bon programmeur n'est rempli que d'horreurs.
C'est faux.
Nan !
Ce fameux "void" : c'est quoi cette abomination de la programmation
? Il n'y a aucune sémantique valable là derrière.
Si : il correspond à une tournure impérative et pas interrogative, il
a à peu près autant de sens qu'un point d'exclamation par rapport à
un point d'interrogation.
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.
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.
Comment se fait il qu'on puisse écrire dans la 11e case d'un
tableau de 10 éléments.
On ne peut pas, tu te trompes.
#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 ? Qu'est-il
donc sensé faire dans cette case qui n'existe pas mais dans laquelle on
peut écrire ? Serait-ce une case void ?
Ce langage surestime beaucoup les capacités des personnes qui vont
l'utiliser.
Quand c'est toi qui l'écris, probablement, en effet. Quand c'est moi,
ce n'est pas le cas.
Le C est un langage démagogique qui a du succès car il fait croire au
programmeur qu'il est le meilleur, qu'il est parfait et qu'il ne fait
jamais d'erreur. Un véritable informaticien sait qu'un système, quel
qu'il soit, machine ou programmeur, n'a aucun moyen de savoir si il est
erroné. Si il le croit, c'est qu'il est incohérent, car seul un être
incohérent peut se croire sans défaut.
En C : tant pis c'est perdu. Un trou de mémoire ?
Tous les programmeurs ne sont pas aussi laxistes, loin de là.
Bien sûr, c'est toujours le programmeur qui est en tort. Le langage n'y
est pour rien : un bon programmeur programme bien quel que soit le langage.
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.
Dès que les programmes ont commencé à ne plus rentrer sur une
disquette ils sont devenus beaucoup trop compliqués pour
fonctionner correctement.
C'est parfaitement faux. Au contraire, les contraintes de taille plus
faibles permettent une programmation plus modulaire et plus claire,
donc des programmes plus simples qui font pourtant plus de choses.
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.
Vous avez beau vous croire parfait, vous n'échappez pas à la règle.
Regardez les codes sources d'un programme en C. Même le code d'un bon programmeur n'est rempli que d'horreurs.
C'est faux.
Nan !
Ce fameux "void" : c'est quoi cette abomination de la programmation ? Il n'y a aucune sémantique valable là derrière.
Si : il correspond à une tournure impérative et pas interrogative, il a à peu près autant de sens qu'un point d'exclamation par rapport à un point d'interrogation.
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.
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.
Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de 10 éléments.
On ne peut pas, tu te trompes.
#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 ? Qu'est-il donc sensé faire dans cette case qui n'existe pas mais dans laquelle on peut écrire ? Serait-ce une case void ?
Ce langage surestime beaucoup les capacités des personnes qui vont l'utiliser.
Quand c'est toi qui l'écris, probablement, en effet. Quand c'est moi, ce n'est pas le cas.
Le C est un langage démagogique qui a du succès car il fait croire au programmeur qu'il est le meilleur, qu'il est parfait et qu'il ne fait jamais d'erreur. Un véritable informaticien sait qu'un système, quel qu'il soit, machine ou programmeur, n'a aucun moyen de savoir si il est erroné. Si il le croit, c'est qu'il est incohérent, car seul un être incohérent peut se croire sans défaut.
En C : tant pis c'est perdu. Un trou de mémoire ?
Tous les programmeurs ne sont pas aussi laxistes, loin de là.
Bien sûr, c'est toujours le programmeur qui est en tort. Le langage n'y est pour rien : un bon programmeur programme bien quel que soit le langage.
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.
Dès que les programmes ont commencé à ne plus rentrer sur une disquette ils sont devenus beaucoup trop compliqués pour fonctionner correctement.
C'est parfaitement faux. Au contraire, les contraintes de taille plus faibles permettent une programmation plus modulaire et plus claire, donc des programmes plus simples qui font pourtant plus de choses.
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.
Vous avez beau vous croire parfait, vous n'échappez pas à la règle.
-- Joe Cool
JKB
Le 08-03-2005, à propos de Re: a-t-on le choix ?, Rakotomandimby (R12y) Mihamina écrivait dans fr.comp.os.linux.debats :
( Tue, 08 Mar 2005 19:13:29 +0000 ) JKB :
J'avais écrit un code de division de polynôme dans GF(2**256) pour faire du décodage souple de codes en blocs.
dites... vous pouvez pas faire des choses humaines :-) ?
Comment ça, ce n'est pas humain ? Et faire une thèse sur la vertu des points virgules dans les pensées de Pascal ou sur l'hermaphrodisme supposé des marmottes d'Outre Quiévrain, c'est plus humain ?
JKB
Le 08-03-2005, à propos de
Re: a-t-on le choix ?,
Rakotomandimby (R12y) Mihamina écrivait dans fr.comp.os.linux.debats :
( Tue, 08 Mar 2005 19:13:29 +0000 ) JKB :
J'avais écrit un code de division de polynôme dans
GF(2**256) pour faire du décodage souple de codes en blocs.
dites... vous pouvez pas faire des choses humaines :-) ?
Comment ça, ce n'est pas humain ? Et faire une thèse sur la vertu
des points virgules dans les pensées de Pascal ou sur
l'hermaphrodisme supposé des marmottes d'Outre Quiévrain, c'est plus
humain ?
Le 08-03-2005, à propos de Re: a-t-on le choix ?, Rakotomandimby (R12y) Mihamina écrivait dans fr.comp.os.linux.debats :
( Tue, 08 Mar 2005 19:13:29 +0000 ) JKB :
J'avais écrit un code de division de polynôme dans GF(2**256) pour faire du décodage souple de codes en blocs.
dites... vous pouvez pas faire des choses humaines :-) ?
Comment ça, ce n'est pas humain ? Et faire une thèse sur la vertu des points virgules dans les pensées de Pascal ou sur l'hermaphrodisme supposé des marmottes d'Outre Quiévrain, c'est plus humain ?
JKB
Nicolas George
JKB , dans le message , a écrit :
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.
J'en ai vu pas mal, au contraire. Et je peux t'assurer que je m'efforce de suivre scrupuleusement la norme dans la plupart de mes programmes, même dans ses exigences qui ne risquent pas de poser problème sur des implémentations existantes (je pense au particulier à l'interdiction de calculer un pointeur invalide, même si on ne le déréférence pas). En général, je pense n'y arriver pas si mal avec l'aide d'outils de vérification assez évolués pour me dénicher les erreurs d'innatention.
Sauf que dès qu'on met ça dans un tableau, on a des surprises ! Parce que l'élément suivant n'est pas du tout où le compilo s'attend à le trouver.
Gnî ? L'élément suivant, il est à p + 1, toujours.
Par ailleurs, lorsqu'un code est écrit par plusieurs personnes, il y a toujours des casts malheureux qui ne dérange pas _sauf_ lorsqu'on change d'architecture où tout se casse la gueule (sjmea).
Ah ça, les programmeurs qui font les choses correctement sont rares, alors en trouver deux au même endroit...
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.
Même de mémoire, pas moyen de voir le genre de construction qui pose problème ?
JKB , dans le message <slrnd2ruab.mkg.knatschke@rayleigh.systella.fr>, a
écrit :
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.
J'en ai vu pas mal, au contraire. Et je peux t'assurer que je m'efforce de
suivre scrupuleusement la norme dans la plupart de mes programmes, même dans
ses exigences qui ne risquent pas de poser problème sur des implémentations
existantes (je pense au particulier à l'interdiction de calculer un pointeur
invalide, même si on ne le déréférence pas). En général, je pense n'y
arriver pas si mal avec l'aide d'outils de vérification assez évolués pour
me dénicher les erreurs d'innatention.
Sauf que dès qu'on met ça dans un tableau, on a des surprises !
Parce que l'élément suivant n'est pas du tout où le compilo s'attend
à le trouver.
Gnî ? L'élément suivant, il est à p + 1, toujours.
Par ailleurs, lorsqu'un code est écrit par plusieurs
personnes, il y a toujours des casts malheureux qui ne dérange pas
_sauf_ lorsqu'on change d'architecture où tout se casse la gueule
(sjmea).
Ah ça, les programmeurs qui font les choses correctement sont rares, alors
en trouver deux au même endroit...
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.
Même de mémoire, pas moyen de voir le genre de construction qui pose
problème ?
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.
J'en ai vu pas mal, au contraire. Et je peux t'assurer que je m'efforce de suivre scrupuleusement la norme dans la plupart de mes programmes, même dans ses exigences qui ne risquent pas de poser problème sur des implémentations existantes (je pense au particulier à l'interdiction de calculer un pointeur invalide, même si on ne le déréférence pas). En général, je pense n'y arriver pas si mal avec l'aide d'outils de vérification assez évolués pour me dénicher les erreurs d'innatention.
Sauf que dès qu'on met ça dans un tableau, on a des surprises ! Parce que l'élément suivant n'est pas du tout où le compilo s'attend à le trouver.
Gnî ? L'élément suivant, il est à p + 1, toujours.
Par ailleurs, lorsqu'un code est écrit par plusieurs personnes, il y a toujours des casts malheureux qui ne dérange pas _sauf_ lorsqu'on change d'architecture où tout se casse la gueule (sjmea).
Ah ça, les programmeurs qui font les choses correctement sont rares, alors en trouver deux au même endroit...
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.
Même de mémoire, pas moyen de voir le genre de construction qui pose problème ?
